Xenocrisis para Super Nintendo/Famicom

18, 9, 10, 11, 12, 13
Pues me llegó el paquete a la mañana y lo pude probar de manera intermitente, pero ahora ya he terminado después de una sesión de un par de horas seguidas.

En resumen es un poco lo que he leído en algunos comentarios, me pasé otras versiones y esta se siente diferente desde la primera sala. Donde me saturó el juego fue en la segunda fase del desierto. Los gusanos eran ya incontrolables y los huecos libres escasísimos, me ha parecido la versión más dura de todas en este sentido, hasta el punto de cogerle rabia al desierto.

También se sufre MUCHO en la última fase donde las torretas multidireccionales disparan a todos lados y encima te vienen los bichos del escudo que te cierran zonas (en otras versiones también acaparan X zona pero aquí es que te quedas sin hueco para hacer nada).

Al final le pedí ayuda a mi hermano, la última fase no pude superarla aún en solitario. Es muy agobiante la sensación constante de no estar seguro en ningún lugar.

Y cuando me puse mano a mano con él, lo del flickering a veces llegaba a lo absurdo y no solo en bosses, si la pantalla del desierto se llenan de gusanos y estáis disparando ambos jugadores, los proyectiles de los gusanos apenas se aprecian en muchas ocasiones o cuando los murciélagos esos disparan los 3 disparos esos.

Del segundo boss acabo de leer un poco por encima el post y... Sí, hay flickering. Si flickering significa parpadeo, sufre y no es poco y con diferencia es la versión que más lo sufre. Parpadea jugando solo y a dobles a otro nivel. Aquí tendrían que haberle cortado un poco la cola a la serpiente, ha quedado muy cutre el resultado.

No he probado aún lo de ir al menú de compra en castellano para ver si ahí también da problemas.

Me ha gustado la transparencia de la primera fase de Ctuhulu o como se escriba. A diferencia de otras versiones que parpadea, aquí la transparencia es tal y como imagino que se pensó. El efecto de la lluvia del bosque es un poco "meh", se agradece el detalle pero me hubiera gustado una lluvia más intensa en vez de esas ráfagas de gotas que no da la sensación de caigan en el suelo. El efecto que les ha quedado bien fue el de la fase de ctuhulu que la niebla se iba cuando no hay bichos para matar. Eso sí, se han pasado usando transparencias para algunas cosas, cuando pillé el lanzallamas disparaba fuego transparente en vez de "sólido" y daba la sensación que por ello era menos potente que en otras versiones, pero vaya, que eso es opinión mía.

Por lo demás, me ha encantado el packagin, la caja muy lograda y sin muescas ni nada por ningún lado.

Que lleve chip, una gráfica Nvidia o una Raspberry o lo que sea, me da igual la verdad.

Como añadido a la colección, me gusta. Pero opino lo mismo que mi hermano cuando nos lo terminamos... De jugar de nuevo a Xeno Crisis, será a otra versión que te permita respirar durante el gameplay.
dr apocalipsis escribió:el número de sprites por línea no es la única limitación que pueda forzar que se dejen de dibujar sprites. De ser así, la Snes sería superior a la Megadrive (32 SNES por 20 de Megadrive).

En la escena de la serpiente es mucho más fácil superar los 272 sprite pixels por scanline de la SNES que los 20 sprites por scanline de la Mega Drive, ya que la segunda no tiene problemas en usar un sólo sprite por pieza de serpiente.

Como la serpiente tiene 8 piezas, sobran 12 sprites para los protagonistas y sus balas.
Bad Apple escribió:Pues me llegó el paquete a la mañana y lo pude probar de manera intermitente, pero ahora ya he terminado después de una sesión de un par de horas seguidas.

En resumen es un poco lo que he leído en algunos comentarios, me pasé otras versiones y esta se siente diferente desde la primera sala. Donde me saturó el juego fue en la segunda fase del desierto. Los gusanos eran ya incontrolables y los huecos libres escasísimos, me ha parecido la versión más dura de todas en este sentido, hasta el punto de cogerle rabia al desierto.

También se sufre MUCHO en la última fase donde las torretas multidireccionales disparan a todos lados y encima te vienen los bichos del escudo que te cierran zonas (en otras versiones también acaparan X zona pero aquí es que te quedas sin hueco para hacer nada).

Al final le pedí ayuda a mi hermano, la última fase no pude superarla aún en solitario. Es muy agobiante la sensación constante de no estar seguro en ningún lugar.

Y cuando me puse mano a mano con él, lo del flickering a veces llegaba a lo absurdo y no solo en bosses, si la pantalla del desierto se llenan de gusanos y estáis disparando ambos jugadores, los proyectiles de los gusanos apenas se aprecian en muchas ocasiones o cuando los murciélagos esos disparan los 3 disparos esos.

Del segundo boss acabo de leer un poco por encima el post y... Sí, hay flickering. Si flickering significa parpadeo, sufre y no es poco y con diferencia es la versión que más lo sufre. Parpadea jugando solo y a dobles a otro nivel. Aquí tendrían que haberle cortado un poco la cola a la serpiente, ha quedado muy cutre el resultado.

No he probado aún lo de ir al menú de compra en castellano para ver si ahí también da problemas.

Me ha gustado la transparencia de la primera fase de Ctuhulu o como se escriba. A diferencia de otras versiones que parpadea, aquí la transparencia es tal y como imagino que se pensó. El efecto de la lluvia del bosque es un poco "meh", se agradece el detalle pero me hubiera gustado una lluvia más intensa en vez de esas ráfagas de gotas que no da la sensación de caigan en el suelo. El efecto que les ha quedado bien fue el de la fase de ctuhulu que la niebla se iba cuando no hay bichos para matar. Eso sí, se han pasado usando transparencias para algunas cosas, cuando pillé el lanzallamas disparaba fuego transparente en vez de "sólido" y daba la sensación que por ello era menos potente que en otras versiones, pero vaya, que eso es opinión mía.

Por lo demás, me ha encantado el packagin, la caja muy lograda y sin muescas ni nada por ningún lado.

Que lleve chip, una gráfica Nvidia o una Raspberry o lo que sea, me da igual la verdad.

Como añadido a la colección, me gusta. Pero opino lo mismo que mi hermano cuando nos lo terminamos... De jugar de nuevo a Xeno Crisis, será a otra versión que te permita respirar durante el gameplay.


Nunca he considerado en este juego,una zona,como segura.Esta versión,debe ser caotica,a dos players.
Las otras versiones que he probado,md,ngcd y n64,salvo la última,se me hace imposible jugarlas,debido a su control.
Otra cosa que no se comenta es........que guarda el record!!!
Bueno tiene una entrada USB esa placa no ? Igual sacan alguna actualización que mejore esos pocos fallos .
Me ha matado eso que tampoco usa el chip de sonido de SNES . Joder todo el mundo esperaba que se hubiera descubierto el como programar en condiciones para SNES ahora y resulta que están tirando de la PI para casi todo . Con lo que es entendible que a más de alguno le haya dado un bajón considerable al ver cómo se ha programado.
A mí personalmente me da igual , lo que quiere uno son resultados y si esa PI ayuda a una nueva oleada de juegos en SNES pues bienvenida .
Como si sacan el Mario 64 con una pi de esas en la SNES , que vamos lo compraba gustosamente [ayay]
Existe una posibilidad de hacer el boss de la serpiente dibujando cada fragmento del bicho en un plano, y usando el hdma para posicionar cada uno de ellos en un punto de la pantalla hasta completar el gráfico de ese enemigo. De esta forma no habría ningún parpadeo, y podría haber toda la tralla en pantalla que quieras.

Para algo así haría falta mucha capacidad para interrumpir la pantalla lo suficientemente rápido dado que se trataría de superponer varios fragmentos de un solo plano en la misma horizontal (una burrada)... pero es que lleva un procesador bastante gordo en el cartucho, ¿que mas hace falta?.


No lo veo del todo claro, pero podría ser viable. Le doy un 30% de posibilidad.


Hacer streaming de sonido para la música son dos canales para estéreo a tope de calidad, y el resto, para el sonido, a calidad normal. El spc700 es suficiente, si no lo emplean tampoco ya, pues nada, otra mas.

No es que sea uno un purista extremo (bueno, ya me callo), pero joder... joder... creo que algo se puede entender que esta versión haya decepcionado.
Señor Ventura escribió:Existe una posibilidad de hacer el boss de la serpiente dibujando cada fragmento del bicho en un plano, y usando el hdma para posicionar cada uno de ellos en un punto de la pantalla hasta completar el gráfico de ese enemigo.

No, no existe esa posibilidad. Con HDMA no se podría mostrar más de un trozo de serpiente en cada scanline, ya que no permite multiplexar fondos en la misma scanline.
Para mostrar la serpiente utilizando fondos habría que utilizar un fondo para cada trozo de serpiente, ocho fondos en total.

Como el HDMA no permite aumentar el número de fondos disponible en cada línea horizontal de la pantalla, lo que propones ni es posible ni tiene sentido. Que es una burrada, vamos.
VempireX está baneado del subforo por "flames"
No sabes de lo que estás hablando como para permitirte decir que digo sinsentidos y burradas.
Sabiendo que les sobraba memoria ¿no podrían haber hecho los sprites de los personajes y de las secciones de la serpiente de 32x32 (y de 8x8 para las balas)?
De esta forma no llegaría al límite de sprites por línea y difícilmente a esos 272 sprite píxels que se comentan (que ya es un tamaño más grande que la resolución horizontal típica que proporciona la consola en la mayoría de sus modos), corregidme si me equivoco.
Lo fácil fácil hubiera sido usar dos planos para hacer dos secciones de esa serpiente, pero lo verdaderamente interesante sería lo que comento de usar un plano para dibujar cada parte de ella en su horizontal mediante interrupciones. Hace falta potencia de proceso, pero es que lleva un procesador en el cartucho.

TMNT IV usa ese mismo principio para el efecto de zoom cuando lanzas los ninjas hacia la pantalla, y street fighter 2 en el escenario de blanka divide el dibujo de un plano haciendo que se separen verticalmente cuando saltas.

Pero hacer esas modificaciones en la horizontal ahí si ya lleva chicha. Si vas a hacer eso de una forma compleja no se cuanta cpu puedes llegar a necesitar, pero de lograrse, puedes hacer esa serpiente exclusivamente con un plano, y sin ocupar ancho de banda.


Con estas cosas se trata siempre de probar.
MasterDan escribió:Sabiendo que les sobraba memoria ¿no podrían haber hecho los sprites de los personajes y de las secciones de la serpiente de 32x32 (y de 8x8 para las balas)?
De esta forma no llegaría al límite de sprites por línea y difícilmente a esos 272 sprite píxels que se comentan (que ya es un tamaño más grande que la resolución horizontal típica que proporciona la consola en la mayoría de sus modos), corregidme si me equivoco.

Las piezas pequeñas de la serpiente ya parece que son de 32x32. Cuando la serpiente se pone en horizontal, las 7 piezas pequeñas ya suman 224 pixels. Si a eso le sumas la cabeza de la serpiente, el sprite del prota y alguna bala, ya se sobrepasa el límite de los 272 pixels. Al menos a dobles se debe sobrepasar con frecuencia.

Señor Ventura escribió:Lo fácil fácil hubiera sido usar dos planos para hacer dos secciones de esa serpiente, pero lo verdaderamente interesante sería lo que comento de usar un plano para dibujar cada parte de ella en su horizontal mediante interrupciones. Hace falta potencia de proceso, pero es que lleva un procesador en el cartucho.

TMNT IV usa ese mismo principio para el efecto de zoom cuando lanzas los ninjas hacia la pantalla, y street fighter 2 en el escenario de blanka divide el dibujo de un plano haciendo que se separen verticalmente cuando saltas.

Pero hacer esas modificaciones en la horizontal ahí si ya lleva chicha. Si vas a hacer eso de una forma compleja no se cuanta cpu puedes llegar a necesitar, pero de lograrse, puedes hacer esa serpiente exclusivamente con un plano, y sin ocupar ancho de banda.

Ni el TMNT IV, ni el Street Fighter 2, ni ningún juego de la SNES incrementa el número de planos disponible en una línea horizontal de la pantalla con interrupciones. No se puede, por mucha CPU que haya disponible.

Tampoco se pueden usar dos planos para hacer dos secciones de la serpiente, ya que uno de ellos debe ser de 4 colores por tile, en vez de 16.
kusfo79 escribió:
stormlord escribió:Si han implementado el sistema de flickering, mal o bien, quiere decir que hay flickering en ciertas partes, digo yo. No sé por qué hay que darle tantas vueltas a las cosas para intentar demostrar lo contrario.

Lo curioso es que sin tener el código en la mano del juego se digan tantas cosas, ¿o en algún lado está la información?

Con la Rom, se podría mirar en Mesen si es flickering o no.

@Señor Ventura @mcfly

Dicho esto, tiene toda la pinta de flickering. Normalmente, los sistemas de flickering no esconden sprites, solo cambian el orden en que son enviados al SAT, por lo que cada frame desaparecen sprites diferentes. NO dejan de dibujar sprites. Por eso, esto tiene toda la pinta de flickering

Ojo, que estáis analizándolo desde un vídeo de Youtube que muy probablemente se está comiendo frames de gratis.

Esto hay que verlo en el hardware real.
kusfo79 escribió:Normalmente, los sistemas de flickering no esconden sprites, solo cambian el orden en que son enviados al SAT, por lo que cada frame desaparecen sprites diferentes. NO dejan de dibujar sprites.

Los juegos de NES suelen hacer eso porque no suele importar las prioridades entre los sprites del sistema de flickering (no importa que dos balas que se superponen cambien sus prioridades en cada frame).

Si se hiciera eso con la serpiente del Xeno Crisis, como las piezas siempre se superponen, sus prioridades cambiarían constantemente y quedaría igual o peor que el sistema actual.

Hubiera estado bien usar ese sistema o el que están usando ahora sólo cuando hace falta. El problema es que se usa más de la cuenta. Otra opción hubiera sido reducir el número de piezas de la serpiente.
VempireX está baneado del subforo por "flames"
@Diskover
Los míos no se comen ningún frame, XD
Además, ya lo está comentando la gente que lo hemos jugado, que el flikering en ese jefe , es bestial jugando a dobles, y lo de la pantalla de mejoras, es de risa, si a eso le sumas, que la música del Boss 2, cuando empieza, parece que estén rayando un vinilo, pues mucho no se han lucido; por cierto, el contacto para devolucion lo sabe alguien si tienen alguna manera de atender directamente? Lo digo por que me llegó la caja bastante tocada, y si no van a arreglar el tema del sonido del Boss 2, lo devuelvo completo.
Diskover escribió:
kusfo79 escribió:
stormlord escribió:Si han implementado el sistema de flickering, mal o bien, quiere decir que hay flickering en ciertas partes, digo yo. No sé por qué hay que darle tantas vueltas a las cosas para intentar demostrar lo contrario.

Lo curioso es que sin tener el código en la mano del juego se digan tantas cosas, ¿o en algún lado está la información?

Con la Rom, se podría mirar en Mesen si es flickering o no.

@Señor Ventura @mcfly

Dicho esto, tiene toda la pinta de flickering. Normalmente, los sistemas de flickering no esconden sprites, solo cambian el orden en que son enviados al SAT, por lo que cada frame desaparecen sprites diferentes. NO dejan de dibujar sprites. Por eso, esto tiene toda la pinta de flickering

Ojo, que estáis analizándolo desde un vídeo de Youtube que muy probablemente se está comiendo frames de gratis.

Esto hay que verlo en el hardware real.

He puesto fotos muy aclaratorias.
(mensaje borrado)
Pues visto lo visto se han tocado los huevos pero bien.
me parece acojonante que tengamos smash tv ,de 1991,practicamente de salida con la consola con 4 miseros megas (creo) y que haga cosas como esta sin una raspberry dentro


comprendo que a esta gente le intersa sacar tajada y obtener beneficios rapidamente ,pero coño ,se lo podrian currar mas
riffraff escribió:Por lo visto lo que sí se están saltando es el chip de sonido: se hace streaming de todo el audio a través de los pines de audio del cartucho.


Sospeché lo del audio desde el primer momento que estuve jugando y escuché como sonaba, ademas que demasiado tiempo y trabajo samplear todas las canciones, habran hecho un "mp3" y a darle al play. Estaria bien averiguar de cuanto es la rom.
Melkor^ escribió:Estaria bien averiguar de cuanto es la rom.

Probablemente la ROM sea muy pequeña por no contener ni los gráficos ni la música ni el código del juego, y todo eso se lea desde otra región de memoria que se pueda actualizar con el puerto USB del cartucho.
titorino escribió:Pues visto lo visto se han tocado los huevos pero bien.
me parece acojonante que tengamos smash tv ,de 1991,practicamente de salida con la consola con 4 miseros megas (creo) y que haga cosas como esta sin una raspberry dentro


comprendo que a esta gente le intersa sacar tajada y obtener beneficios rapidamente ,pero coño ,se lo podrian currar mas


¿Me estás diciendo que no notas que los sprites de Xenocrisis son bastante más grandes, y están mucho más animados, que los del Smash T.V.?

Por no hablar de que también flickea de lo lindo.
@titorino, Smash TV está bastante por debajo.
riffraff escribió:
Melkor^ escribió:Estaria bien averiguar de cuanto es la rom.

Probablemente la ROM sea muy pequeña por no contener ni los gráficos ni la música ni el código del juego, y todo eso se lea desde otra región de memoria que se pueda actualizar con el puerto USB del cartucho.

Es una buena pregunta, pero yo apostaría a que son bastante más de 32 megas.

stormlord escribió:@titorino, Smash TV está bastante por debajo.

En ese boss los sprites casi nunca coinciden en línea (en la horizontal) y cuando lo hacen también parpadea, pero vamos, era algo totalmente normal en los juegos. De todas formas, para mí el Xeno es un juego más demandante en general
AtomicRobot-nik16 escribió:
riffraff escribió:Probablemente la ROM sea muy pequeña por no contener ni los gráficos ni la música ni el código del juego, y todo eso se lea desde otra región de memoria que se pueda actualizar con el puerto USB del cartucho.

Es una buena pregunta, pero yo apostaría a que son bastante más de 32 megas.

Si el tema es que puede que la mayoría de los datos no estén en una ROM, sino en una memoria tipo SD gestionada por un sistema de ficheros (al estilo Nintendo DS).
AtomicRobot-nik16 escribió:En ese boss los sprites casi nunca coinciden en línea (en la horizontal) y cuando lo hacen también parpadea, pero vamos, era algo totalmente normal en los juegos. De todas formas, para mí el Xeno es un juego más demandante en general


El problema que veo yo al menos es que en el Xenocrisis el Boss parpadea cuando está en vertical también y de manera más pronunciada. Si lo hiciera cuando sobrecarga un scanline sería comprensible, pero lo hace cuando le da la gana.
MasterDan escribió:
AtomicRobot-nik16 escribió:En ese boss los sprites casi nunca coinciden en línea (en la horizontal) y cuando lo hacen también parpadea, pero vamos, era algo totalmente normal en los juegos. De todas formas, para mí el Xeno es un juego más demandante en general


El problema que veo yo al menos es que en el Xenocrisis el Boss parpadea cuando está en vertical también y de manera más pronunciada. Si lo hiciera cuando sobrecarga un scanline sería comprensible, pero lo hace cuando le da la gana.


El boss de Smash T.V, bueno, y toda la escena en general, apenas cambia tiles y son sprites muy pequeños.
En Xenocrisis son sprites más grandes y no para de refrescarlos, tanto en el jefe como en el resto de la escena.

Ya se ha dicho varias veces, a SNES no le cuesta tanto mover muchos sprites pequeños, lo que le cuesta es refrescar los tiles. El límite de sprites por línea no es el único que puede hacer que un sprites se descarte.
se pefectamente que smash tv es mas discreto (no mucho) ,tambien hay que ponerse en contexto que es un juego de primera hornada y de muy escasos megas .
a lo que voy es que se lo podrian haber currado ,solo eso,es que encima que para correr meten una raspberry no esta ni aprovechada
dr apocalipsis escribió:
MasterDan escribió:
AtomicRobot-nik16 escribió:En ese boss los sprites casi nunca coinciden en línea (en la horizontal) y cuando lo hacen también parpadea, pero vamos, era algo totalmente normal en los juegos. De todas formas, para mí el Xeno es un juego más demandante en general


El problema que veo yo al menos es que en el Xenocrisis el Boss parpadea cuando está en vertical también y de manera más pronunciada. Si lo hiciera cuando sobrecarga un scanline sería comprensible, pero lo hace cuando le da la gana.


El boss de Smash T.V, bueno, y toda la escena en general, apenas cambia tiles y son sprites muy pequeños.
En Xenocrisis son sprites más grandes y no para de refrescarlos, tanto en el jefe como en el resto de la escena.

Ya se ha dicho varias veces, a SNES no le cuesta tanto mover muchos sprites pequeños, lo que le cuesta es refrescar los tiles. El límite de sprites por línea no es el único que puede hacer que un sprites se descarte.

Sin entrar en conspiraciones ni piques, si el juego ha quedado así es porque entiendo que no han dado con una solución al 100%, que por otro lado, tampoco tiene sentido complicarse la vida optimizando mil años algo que era normal en juegos de entonces y que tampoco afecta tanto. De hecho, la mayoría de activos del juego ya los tenían, por lo que todo el tiempo se habrá dedicado a adaptarlo a la consola. Les ha quedado así y ya está, bastante es haberse estrenado en Snes con esta calidad, creo yo. Luego estoy seguro que habrá aspectos que a nosotros se nos escapen, tendemos a simplificar porque no entendemos lo que pasa realmente.

Todas las versiones han salido muy bien y amoldadas a cada sistema, no creo que la versión Snes tenga que ser la excepción, lo que pasa es lo que ya sabemos que pasa siempre, cuesta aceptar algunas cosas y alivia más pensar que son los programadores quienes tienen la culpa, que simplemente aceptar que es una consola con más de 30 años con sus pros, contras y peculiaridades. ¿Podría haber sido mejor? quizás sí, pero a ver quien les demuestra lo contrario porque no abundan los ejemplos. Imagino que serán novatos en Snes, tampoco será programación en ensamblador...

Digo esto basándome en los hechos, porque a B.Bureau se les puso en un altar desde el principio precisamente por su profesionalidad, recuerdo debates haciendo comparativas frente a otras compañías indies y poniendoles como el referente a seguir, creo que ahora se merecerían como mínimo el beneficio de la duda, antes de reprocharles. Supongo que ellos irán explicando cosas con el tiempo.

Y ya puestos, ¿se sabe quién ha programado el juego específicamente? Porque no creo que sean las mismas personas las que han hecho todas las versiones.
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.
@stormlord Los usuarios de MSX no opinan lo mismo XD
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.

Los ports de Amstrad y MSX no llevaban un coprocesador del 2012.
riffraff escribió:
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.

Los ports de Amstrad y MSX no llevaban un coprocesador del 2012.


Es que también lo de quejarse de que no esté programado en ensamblador cuando va con un ARM de doble núcleo a 133mhz, que como si fuese en basic, vaya. Es como quejarse de que no hayan puesto más de 4 paletas en Megadrive y no aceptar lo que es una infranqueable limitación de hardware.

También te digo, no he oído a nadie quejarse por las versiones de NeoGeo, N64 o Dreamcast.
dr apocalipsis escribió:Es que también lo de quejarse de que no esté programado en ensamblador

¿Quién se ha quejado de eso?

dr apocalipsis escribió:no he oído a nadie quejarse por las versiones de NeoGeo, N64 o Dreamcast.

Que yo sepa, esas versiones no tienen fallos gráficos evitables.
titorino escribió:Pues visto lo visto se han tocado los huevos pero bien.
me parece acojonante que tengamos smash tv ,de 1991,practicamente de salida con la consola con 4 miseros megas (creo) y que haga cosas como esta sin una raspberry dentro


comprendo que a esta gente le intersa sacar tajada y obtener beneficios rapidamente ,pero coño ,se lo podrian currar mas


ESTO si es flickering. ¿Los fragmentos del cuerpo de la serpiente del xeno crisis son de 32x32 pixels?.

Yo no voy a decir mas al respecto de la teoría del plano+hdma para que me contesten negando que se pueden hacer cosas que no he afirmado que se puedan hacer. Soluciones hay, quien sea capaz de entender de lo que hablo, perfecto, y quien no lo sea, lo siento, no pasa nada.

El juego sigue estando bien aunque desde la curiosidad técnica me decepcione, pero ya solo por el mando tiene que merecer la pena la experiencia. Sobre la música, me gustaría saber que solución han usado, aunque me la imagino.
Yo creo que Bitmap un poco vagos si han sido. Si tienes flickering en el menú de la tienda de mejoras rediseñala para que esto no pase, tan fácil como poner los iconos de las mejoras arriba en horizontal y debajo el texto y la barra de niveles.

Es que es lamentable tener flickering en un menú y pasar del tema.

riffraff escribió:
Melkor^ escribió:Estaria bien averiguar de cuanto es la rom.

Probablemente la ROM sea muy pequeña por no contener ni los gráficos ni la música ni el código del juego, y todo eso se lea desde otra región de memoria que se pueda actualizar con el puerto USB del cartucho.


Bastante decepcionante si eso va asi.
El flickeo de la sepiente és muy similar a este boss de Biohazard Battle, que también es juego que soporta dos jugadores.



Puede no ser lo más deseable visualmente, pero és un recurso para no borrar las líneas de sprites por completo, en maquinitas limitadas.
riffraff escribió:
dr apocalipsis escribió:Es que también lo de quejarse de que no esté programado en ensamblador

¿Quién se ha quejado de eso?

dr apocalipsis escribió:no he oído a nadie quejarse por las versiones de NeoGeo, N64 o Dreamcast.

Que yo sepa, esas versiones no tienen fallos gráficos evitables.


Páginas atrás desprecian a BB por no usar ensamblador en ninguna de las 2 versiones.

Y otras versiones no tienen ni una sola mejora sobre el original, ni un detalle que utilice alguna funcionalidad icónica de su hard. Podrían ser una emulación e irían igual.

Es como quejarse de que en los ports del Street Fighter no se usaran sombras transparentes silueteadas cuando podrían haberlo hecho. Y, fíjate, que al final en SNES sí lo han hecho a fuerza de recibir hate por redes sociales.
dr apocalipsis escribió:otras versiones no tienen ni una sola mejora sobre el original, ni un detalle que utilice alguna funcionalidad icónica de su hard. Podrían ser una emulación e irían igual.

Una vez más, que yo sepa, esas versiones no son peores que la de Mega Drive en temas en los que no tenía por qué haber sido peor, como el flickering en los menús.
riffraff escribió:
dr apocalipsis escribió:otras versiones no tienen ni una sola mejora sobre el original, ni un detalle que utilice alguna funcionalidad icónica de su hard. Podrían ser una emulación e irían igual.

Una vez más, que yo sepa, esas versiones no son peores que la de Mega Drive en temas en los que no tenía por qué haber sido peor, como el flickering en los menús.


Siguiendo esa lógica, es normal que SNES sea en peor en un tema en el que es peor que Megadrive.

No veo el problema.
dr apocalipsis escribió:
riffraff escribió:
dr apocalipsis escribió:otras versiones no tienen ni una sola mejora sobre el original, ni un detalle que utilice alguna funcionalidad icónica de su hard. Podrían ser una emulación e irían igual.

Una vez más, que yo sepa, esas versiones no son peores que la de Mega Drive en temas en los que no tenía por qué haber sido peor, como el flickering en los menús.


Siguiendo esa lógica, es normal que SNES sea en peor en un tema en el que es peor que Megadrive.

No veo el problema.

En la SNES es fácil evitar el flickering en los menús, y no les ha dado la gana evitarlo.
Es fácil reducir el flickering en otras secciones con un coprocesador del 2012, y no les ha dado la gana reducirlo.
Que yo sepa, eso no pasa en otros ports.
No debería ser tan difícil entender por qué para algunos (no para todos), este port ha sido una decepción.
riffraff escribió:
dr apocalipsis escribió:otras versiones no tienen ni una sola mejora sobre el original, ni un detalle que utilice alguna funcionalidad icónica de su hard. Podrían ser una emulación e irían igual.

Una vez más, que yo sepa, esas versiones no son peores que la de Mega Drive en temas en los que no tenía por qué haber sido peor, como el flickering en los menús.

No todos los parpadeos son consecuencia de límite de sprites, puede ser otro tipo de bug, o una pequeña corrupción de los gráficos por algún tema de incompatibilidad de los caracteres al cambiar de idioma, como falta de espacio, etc... Eso pasa en algunos juegos oficiales de la época.
riffraff escribió:
dr apocalipsis escribió:
riffraff escribió:Una vez más, que yo sepa, esas versiones no son peores que la de Mega Drive en temas en los que no tenía por qué haber sido peor, como el flickering en los menús.


Siguiendo esa lógica, es normal que SNES sea en peor en un tema en el que es peor que Megadrive.

No veo el problema.

En la SNES es fácil evitar el flickering en los menús, y no les ha dado la gana evitarlo.
Es fácil reducir el flickering en otras secciones con un coprocesador del 2012, y no les ha dado la gana reducirlo.
Que yo sepa, eso no pasa en otros ports.
No debería ser tan difícil entender por qué para algunos (no para todos), este port ha sido una decepción.


Como si le pones un 14900KS al cartucho. El flickering lo impone la PPU de SNES.

Quién esté decepcionado con el port que ponga un ejemplo mejor (por ahora lo 'mejor' que se ha puesto es el Smash T.V) o que lo programe mejor.

Lo de masacrarlo porque a los betatesters se les ha pasado mirar los menús en español, tela. En todo caso, supongo que es otro flickering programado por los desarrolladores para joder y no un límite de la SNES alcanzado por despiste.
Para mí la pregunta es si se podría extrapolar este mismo chip a otra placa custom para que la scene produzca juegos para ella ?!
Sería capaz con este chip SNES tener por ejemplo un Doom en condiciones ? O sacar juegos en 3D casi tan potentes como una N64 ( Un Mario 64 ) ?!
[idea]
Hookun escribió:Para mí la pregunta es si se podría extrapolar este mismo chip a otra placa custom para que la scene produzca juegos para ella ?!
Sería capaz con este chip SNES tener por ejemplo un Doom en condiciones ? O sacar juegos en 3D casi tan potentes como una N64 ( Un Mario 64 ) ?! [idea]



dr apocalipsis escribió:Lo de masacrarlo porque a los betatesters se les ha pasado mirar los menús en español, tela. En todo caso, supongo que es otro flickering programado por los desarrolladores para joder y no un límite de la SNES alcanzado por despiste.

¿Por qué asumes que el flickering del menú se debe a un "despiste"? ¿Eres parte del grupo de desarrollo o tienes relación con ellos?
Es imposible abrir el menú sin ver el flickering.
SOBRE EL TEXTO DEL MENÚ:

-Se puede integrar el texto el plano.

-Se pueden integrar los gráficos de los iconos en el plano.

-Se pueden integrar ambas cosas en el plano.

-Se pueden usar sprites de 8x8 pixels de forma que admite hasta 32 carácteres por línea (todo el área de la pantalla).

Los parpadeos del menú son 100% evitables, ¿que tamaño de sprites usa el texto actualmente?.



SOBRE "DEATH VIPER" (o como se llame):

-El boss de la serpiente tiene al menos la cabeza y la cola con algo mas de 32 pixels de ancho (no es eficiente en snes).

-La serpiente es proporcionalmente mas grande en snes que en el resto de versiones, redibujar para que se vea con el mismo tamaño que el resto de ports no es una tarea titánica (con 20 tiles de sprites por línea haces la serpiente en horizontal, se vería igual en tamano y forma que en el resto de versiones, y te aguantaría sin parpadeos a 2 jugadores, y con todas las bombas que quieras tirar). El resultado podría tener algo menos de definición (el sprite original no perfila cada posible pixel, así que es probable que la diferencia no se note tanto, y en movimiento menos).



SOBRE LA ACTUALIZACIÓN DE TILES:

-La serpiente consta de solo 3 módulos diferentes, y tres posiciones distintas para cada uno de ellos (el resto de ellas para todas las animaciones se consigue espejando horizontal y verticalmente cada "resultado). Es decir, cabe todo en la vram, no hace falta transferir.

-Cuenta con un procesador de apoyo, en caso de haberse hecho transferiendo tienes el 100% de tiempo del DMA.

-El 65816 por si solo no tiene por qué ser incapaz de gestionar la acción en pantalla y actualizar 48 tiles de sprites de un boss (en el peor de los casos).
Señor Ventura escribió:SOBRE LA ACTUALIZACIÓN DE TILES:

-La serpiente consta de solo 3 módulos diferentes, y tres posiciones distintas para cada uno de ellos (el resto de ellas para todas las animaciones se consigue espejando horizontal y verticalmente cada "resultado). Es decir, cabe todo en la vram, no hace falta transferir.

-Cuenta con un procesador de apoyo, en caso de haberse hecho transferiendo tienes el 100% de tiempo del DMA.

-El 65816 por si solo no tiene por qué ser incapaz de gestionar la acción en pantalla y actualizar 48 tiles de sprites de un boss (en el peor de los casos).

Ni de coña renderizas la serpiente en un fondo con sólo 48 tiles únicos.

La mayoría de las posiciones de la serpiente van a requerir muchos más tiles, y como no se puede escribir en la VRAM fuera del VBlank ni meter bandas negras porque no hay sitio, seguramente tocaría bajar a 30FPS con ese enfoque.
riffraff escribió:¿Por qué asumes que el flickering del menú se debe a un "despiste"? ¿Eres parte del grupo de desarrollo o tienes relación con ellos?
Es imposible abrir el menú sin ver el flickering.


No, claro, no ha sido un despiste.

Han montado todo este tinglado para fastidiar y desprestigiar a la Snes.
@riffraff ¿Tu entiendes algo de lo que se dice?. Pregunto en serio.
dr apocalipsis escribió:
riffraff escribió:¿Por qué asumes que el flickering del menú se debe a un "despiste"? ¿Eres parte del grupo de desarrollo o tienes relación con ellos?
Es imposible abrir el menú sin ver el flickering.


No, claro, no ha sido un despiste.

Han montado todo este tinglado para fastidiar y desprestigiar a la Snes.

¿Qué ganan ellos desprestigiando a nadie?

¿No es más fácil que hayan dejado el flickering porque era más rentable no arreglarlo?
649 respuestas
18, 9, 10, 11, 12, 13