Final Fight, ¿por qué X68k, Mega CD y GBA no pudieron con el port?

darksch escribió:¿Qué hack, dónde está para descargar?

En el enlace está todo, pero hay que advertir que por el momento los enemigos ignoran al segundo jugador.

Eso si, ya va faltando menos para terminar con esos detalles antes de ponerse a mejorar gráficos, animaciones, efectos de sonido... como dice su autor, esa será la parte mas divertida del proyecto.

Señor Ventura escribió:

darksch escribió:¿Qué hack, dónde está para descargar?

En el enlace está todo, pero hay que advertir que por el momento los enemigos ignoran al segundo jugador.

Eso si, ya va faltando menos para terminar con esos detalles antes de ponerse a mejorar gráficos, animaciones, efectos de sonido... como dice su autor, esa será la parte mas divertida del proyecto.

Creo que te equivocas en una cosa, no es que vaya a mejorar las animaciones, si te refieres a esto:

Probably the biggest pain in the ass of them all was getting 2 different player characters on-screen at once due to the aforementioned memory limitations. I had to add new logic to decompress animation frame data for 2P in the second RAM bank, as the first bank was full. Then I had to fully reverse-engineer the code that takes action upon this frame data and make a 2P-only version of it to account for it being in a different RAM bank than the other entity's anim frame data. Then I had to tweak the DMA routines to place 2P's tiles in a different area than 1P's tiles. Unfortunately this meant overwriting a lot of tiles for the food and points items, and some impact effect tiles. This is actually still broken and will require extensive tweaking. Also of concern was 2P's palette, which wound up overwriting the greyscale flashing effect for item pickups. Once I got this sorted out, I implemented my Cody hack into this one to get all 3 player characters.

Es mejorar el copiado de las animaciones (los gráficos) del jugador 2 de lo que está hablando. Ahora mismo tiene, según se ve en la imagen (no lo he probado pero supongo que correrá bien), 3 enemigos y 2 jugadores, pero a cambio de muchos problemas con otros elementos como objetos y demás, que es lo que quiere mejorar.

@darksch Bueno, yo hablo de mis conversaciones con el. Tiene la intención de transladar los tilesets directamente del arcade, como por ejemplo la pantalla de elección de personaje (cody, guy, o haggar).

Para los sprites hará falta un redibujado, pero de forma que no ofrezca tantas diferencias con el arcade como con el juego actual, y por supuesto con todos los frames de animación del arcade.

En el hack actual ya ha cambiado algunos tiles de los escenarios, como algunas ventanas del escenario, y tal.

Lo curioso es que habla de "tiles" con los personajes jugadores. Curioso, los enemigos usan los sprites y los jugadores en realidad serían planos de scroll con tiles entonces.
No es mal sistema, en MD por ejemplo podrías coger los final bosses que son tochos y salen en zonas ya sin doble scroll y hacerlos un plano, ganarías muchos px de dibujado horizontal de sprites y podrías meter más enemigos.

De todas formas nada más que leyendo como piensa hacerlo, es imposible que se le dedicara tanto a un juego para intentar hacer tanto truco con la máquina para conseguir el objetivo. El juego no les sale rentable.
Vamos que si en FF2 se decidió por reducir los muñecos para tener 2J y múltiples enemigos no fue por casualidad. Es que para que se pueda hacer normalmente en la máquina es como debía ser. En Capcom eran profesionales que sabían hacer su trabajo. Si nos ponemos a mirar cada línea de bus al final haces virguerías hasta en Spectrum, pero cosa muy distinta es la rentabilidad. Más en concreto la viabilidad, que es lo que se maneja en los negocios.

darksch escribió:Lo curioso es que habla de "tiles" con los personajes jugadores. Curioso, los enemigos usan los sprites y los jugadores en realidad serían planos de scroll con tiles entonces.
No es mal sistema, en MD por ejemplo podrías coger los final bosses que son tochos y salen en zonas ya sin doble scroll y hacerlos un plano, ganarías muchos px de dibujado horizontal de sprites y podrías meter más enemigos.

De todas formas nada más que leyendo como piensa hacerlo, es imposible que se le dedicara tanto a un juego para intentar hacer tanto truco con la máquina para conseguir el objetivo. El juego no les sale rentable.
Vamos que si en FF2 se decidió por reducir los muñecos para tener 2J y múltiples enemigos no fue por casualidad. Es que para que se pueda hacer normalmente en la máquina es como debía ser. En Capcom eran profesionales que sabían hacer su trabajo. Si nos ponemos a mirar cada línea de bus al final haces virguerías hasta en Spectrum, pero cosa muy distinta es la rentabilidad. Más en concreto la viabilidad, que es lo que se maneja en los negocios.

Somos Us Gold&Tiertex ¿que Bus tenemos que pillar para llegar a esa estacion?


Señor Ventura ojala termine el tema,me acuerdo que se inicio un proyecto para Final Fight AGA Amiga 1200 y tenia buena pinta,pero no se termino nunca,ojala este señor lo lleve hasta el final,seria un pasote.

Yo diría, que técnicamente es imposible que te lleguen a matar en las versiones snes de final fight 1 y 2, el 3 no llegué a probarlo

Igual cuando eramos mas frios eramos mas malos, pero yo llegué a aborrecerlos porque no habia dificultad alguna, 3 enemigos ni jugando a mano cambiada xD

AES escribió:Yo diría, que técnicamente es imposible que te lleguen a matar en las versiones snes de final fight 1 y 2, el 3 no llegué a probarlo

Igual cuando eramos mas frios eramos mas malos, pero yo llegué a aborrecerlos porque no habia dificultad alguna, 3 enemigos ni jugando a mano cambiada xD

Debo ser malisimo,bueno mas que malisimo terrible.

El de MegaCD en Mania está bastante bien nivelado. Ese es otro aspecto que tiene la conversión, jugablemente me gusta hasta más que el arcade.

@AES , ponte a jugar al FF1 de Snes, por ejemplo al FF Guy japonés, grabas la partida, y nos enseñas como te lo pasas sin que te maten.

A mí envíame un privado para asegurarme que no me pierdo tu vídeo. Si no envías nada, asumiré que eres un fantasma o un troll, y aunque ya nos conocemos de hace años y tengo más o menos una opinión formada, me gustaría terminar de asentarla.

darksch escribió:Vamos que si en FF2 se decidió por reducir los muñecos para tener 2J y múltiples enemigos no fue por casualidad.

¿Seguro que son mas pequeños que en el final fight 1?.

darksch escribió:En Capcom eran profesionales que sabían hacer su trabajo.

Capcom hacía también sus cosas raras, y en snes malgastaba muchos sprites en casi todos sus juegos. Además, el propio port del final fight de snes si que encierra varias historias sobre los motivos de capcom para no currarse el port por disputas con nintendo.

Optimizando, y si la cpu lo aguanta tal y como está hecho ese código, 6 enemigos a 2 jugadores es una posibilidad real, porque con ese juego se logra disponer del ancho de banda suficiente para dibujarlo todo a 32x32. El problema es tirar al suelo a varios enemigos a la vez, que ahí horizontalmente puedes saturar mas fácilmente la tasa de dibujado horizontal, ya que no ocupan lo mismo horizontalmente cuando están tumbados que cuando están de pié.

Y eso si, se trataría de tener que modificar el código para alterar cada oleada de enemigos, la configuración del tamaño de sprites... es mas trabajo, y por el momento, hasta donde pude ver el autor del hack no se lo plantea.
Existe la posibilidad de usar sprites de 16x32, que paliaría incluso mas la posibilidad de parpadeos usando mas enemigos en pantalla, pero de nuevo es lo mismo, mas trabajo que no forma parte de sus objetivos.

Bueno "malgastaba". Ya se vió que en SNES por su peculiaridad con los sprites no es que sea fácil aprovecharlos. Al ser de tamaño fijo, y tener un número limitado en la tabla de atributos, no se puede tener todo, o número o tamaño.

@Señor Ventura Una cosa es la potencia teoríca y otra la real. Esisten cuellos de botella, problemas de memoria, etc. Luego entra ya la habilidad y conocimiento de los desarrolladores en cada sistema o si la consola era mejor haciendo una cosa u otra.

darksch escribió:Bueno "malgastaba". Ya se vió que en SNES por su peculiaridad con los sprites no es que sea fácil aprovecharlos. Al ser de tamaño fijo, y tener un número limitado en la tabla de atributos, no se puede tener todo, o número o tamaño.

Si, se malgastaban sprites, si. En bastantes juegos de capcom es muy común encontrarse montones de sprites de 16x16 para dibujar solo dos o tres pixels. Y en un sprite de 16x16 hay 256 pixels, para que te hagas una idea.

BMBx64 analizó el king of the dragons, y es un pasote la cantidad de sprites que se tiran directamente a la basura ahí... 4 sprites para el dibujo de un cofre que podrías hacer con menos. Hay imágenes, pero no las encuentro ahora.

varios escribió:@Señor Ventura Una cosa es la potencia teoríca y otra la real. Esisten cuellos de botella, problemas de memoria, etc. Luego entra ya la habilidad y conocimiento de los desarrolladores en cada sistema o si la consola era mejor haciendo una cosa u otra.

A la hora de dibujar los gráficos no hay potencia teórica y potencia real, aquí ya estamos hablando de sota, caballo, y rey.

En el actual port a snes del final fight tienes disponibles 10,63KB por frame para transmitir tiles, actualizar la tabla OAM, la CRAM, y poco mas.

Pongamos que reservas 9KB a cada frame solo para actualizar tiles. Los escenarios ya están guardados en la VRAM, así que parece improbable que algún escenario requiera actualizar la memoria dedicada a los mismos.

Además en la VRAM tienes un límite para almacenar tiles destinadas a los sprites, que ronda los 16KB, y estábamos hablando de poner 6 enemigos y 2 jugadores.

-Andore lo haces con 2 sprites de 32x32 y 2 sprites de 16x16 (en el port actual se usan decenas de sprites en lugar de usar solo 4).
-Haggar lo haces con 1 sprite de 32x32 y 10 sprites de 16x16 (por culpa de su postura, con los btrazos tan abiertos)
-Los masillas con 2 sprites de 32x32 vas sobrado porque van como agazapados.
-Cody con 1 sprite de 32x32 y 9 sprites de 16x16.
-Guy con 1 sprite de 32x32 y 9 sprites de 16x16.

Poner un haggar, un andore, un cody/guy, y cinco enemigos normales, ocupa en memoria 9856 Bytes. Está muy dentro del límite dedicado para sprites en VRAM, pero se pasa un poco de la cantidad que queríamos dedicarle por frame a animarlos, así que restándole un enemigo entra dentro de los requerimientos.

Sin embargo, las animaciones en este juego no implican a todo el muñeco, sino generalmente solo a las piernas, por lo que, así a ojo, con 8 personajes en pantalla solo se requeriría de 3 a 4KB por frame, dependiendo de la escena. No haría falta ni desactivar scanlines para conseguir ancho de banda.

Lo único con lo que habría que tener cuidado es con procurar que no se apelotonen todos los enemigos en una misma zona para evitar los parpadeos, y por supuesto un motor que pueda gestionar un número elevado de IA's.

@Señor Ventura Es mucho más fácil decirlo que luego hacerlo. A la hora de desarrollar el juego influyen muchos factores, entre ellos la fecha de salida, capacidad máxima del cartucho, intentar aprovechar sprites del arcade y no tener que rehacerlos (tocar algo hacía que tuvieran que retocar todo), problemas con las herramientas de desarollo, no arriesgarse a parpadeos o que se realentice, etc
Visto a posteriori se ve todo más fácil.

PD: Tengo que defender a mi gremio,

varios escribió:@Señor Ventura Es mucho más fácil decirlo que luego hacerlo. A la hora de desarrollar el juego influyen muchos factores, entre ellos la fecha de salida, capacidad máxima del cartucho, intentar aprovechar sprites del arcade y no tener que rehacerlos (tocar algo hacía que tuvieran que retocar todo), problemas con las herramientas de desarollo, no arriesgarse a parpadeos o que se realentice, etc
Visto a posteriori se ve todo más fácil.

PD: Tengo que defender a mi gremio,

En realidad tomar la decisión de usar sprites de 8x8 y 16x16 para personajes tan grandes es un despiporre de malgastar slots de la OAM, y para lo demás, pues de nuevo, no influye ningún factor. Como ya he dicho a la hora de dibujar gráficos esto es sota caballo y rey.

De hecho era muy común diseñar los juegos sobre el papel usando cuadrículas para calcular el gasto en bytes, y ya desde ese mismo momento podías saber con cuantos recursos contabas con total precisión.

Otra cosa es saber si vas a poder mover a 6 enemigos a la vez, porque su complejidad no se puede cuantificar.

Señor Ventura escribió:

varios escribió:@Señor Ventura Es mucho más fácil decirlo que luego hacerlo. A la hora de desarrollar el juego influyen muchos factores, entre ellos la fecha de salida, capacidad máxima del cartucho, intentar aprovechar sprites del arcade y no tener que rehacerlos (tocar algo hacía que tuvieran que retocar todo), problemas con las herramientas de desarollo, no arriesgarse a parpadeos o que se realentice, etc
Visto a posteriori se ve todo más fácil.

PD: Tengo que defender a mi gremio,

En realidad tomar la decisión de usar sprites de 8x8 y 16x16 para personajes tan grandes es un despiporre de malgastar slots de la OAM, y para lo demás, pues de nuevo, no influye ningún factor. Como ya he dicho a la hora de dibujar gráficos esto es sota caballo y rey.

De hecho era muy común diseñar los juegos sobre el papel usando cuadrículas para calcular el gasto en bytes, y ya desde ese mismo momento podías saber con cuantos recursos contabas con total precisión.

Otra cosa es saber si vas a poder mover a 6 enemigos a la vez, porque su complejidad no se puede cuantificar.

¿y como haces que no se acumulen en la misma zona de pantalla? ¿Qué se queden parados esperando a atacarte? No es lo mismo un juego sobre railes que uno en el que tienes libertad de movimientos. Además, conforme se va conociendo una consola se van aprovechando mejor sus capacidades. Mejor no pillarse los dedos.

varios escribió:¿y como haces que no se acumulen en la misma zona de pantalla? ¿Qué se queden parados esperando a atacarte?

Basta con que cuando decidan flanquearte no lo hagan en la horizontal, pero vamos, que con 4 enemigos y 2 jugadores, o 5 enemigos a 1 jugador, puedes poner toda la acción a saco que quieras con unos parpadeos mínimos. El final fight del mega cd hace eso, y para mi no tiene nada de malo que exista el flickeo que tenga que existir a cambio de todos esos gráficos.

varios escribió:No es lo mismo un juego sobre railes que uno en el que tienes libertad de movimientos. Además, conforme se va conociendo una consola se van aprovechando mejor sus capacidades. Mejor no pillarse los dedos.

No tiene nada que ver con ir sobre railes.

También hay otras formas de prevenir parpadeos, por ejemplo estableciendo una prioridad de personajes, y no dibujar los sprites que queden perfectamente tapados por todos los demás personajes. Esto sería especialmente útil cuando se agolpan todos y caen tumbados en el suelo (que es cuando mas espacio horizontal ocupan, y donde mas sufre la tasa de relleno), pero ya tienes que estar usando la cpu para identificar cada sprite, determinar si está completamente tapado... puede comer recursos si no programas una rutina para encargarse de esa tarea que no resulte muy pesada.

Y como todo, la clave está en el ingenio.

Se te olvida que en SNES no puedes distribuir como te de la gana esa memoria. Si usan sprites de 16x16 es porque para dibujar el conjunto de todos los de pantalla eran los más equilibrados. Si hay alguno que son 3px, pues mala suerte si el hardware no te permite cambiarles el tamaño para cada sprite.

El que se usen más o menos, va por el diseño de gráficos, al hacerse con patrones que deban encajar, a veces hay que usar otro tile adicional para los bordes, en los cuales te sobran muchos px sin utilizar, pero no hay más remedio.

darksch escribió:Se te olvida que en SNES no puedes distribuir como te de la gana esa memoria.

Vuelve a leer lo que he escrito.

darksch escribió:Si usan sprites de 16x16 es porque para dibujar el conjunto de todos los de pantalla eran los más equilibrados. Si hay alguno que son 3px, pues mala suerte si el hardware no te permite cambiarles el tamaño para cada sprite.

Se usan sprites de 16x16 para dibujar un par de píxeles porque el resto de sprites no aprovechan el espacio: les sobra espacio porque están descentrados.

Si se están usando demasiados sprites para dibujar un personaje, cuando por un puñado lo puedes hacer, es que algo no se está haciendo bien, y no es un impedimento del hardware, sino de no mejorar eso.

darksch escribió:El que se usen más o menos, va por el diseño de gráficos, al hacerse con patrones que deban encajar, a veces hay que usar otro tile adicional para los bordes, en los cuales te sobran muchos px sin utilizar, pero no hay más remedio.

Si no hay mas remedio, ya que estás redibujando puedes obviar un par de pixeles. Si estuvieses transladando un gráfico tal y como es en su juego original, se podría entender, pero si redibujas, además ya no solo estás dejando patente que no estás optimizando el uso de los sprites, sino que además estás redibujando sin precalcular el espacio que va a ocupar.

Estás obviando lo más obvio. Realización. Mientras hacer una matriz bidimensional de un tamaño es lo que casi siempre se usaba por motivos obvios, el componer sprites de la manera que dices requiere que, cada fotograma, sea una composición en sí misma de multitud de sprites de distintos tamaños.

¿Tú sabes exactamente el coste que tiene eso?. Pues para empezar tienes que hacerte un editor de sprites específico para hacer dicha composición. Luego tienes que generar tu propia estructura que es más complicado de hacer, además de más lento, pues mientras en una matriz bidimensional de tamaños iguales indicas sólamente el ancho y alto (2 bytes) y autogeneras fácil y rápidamente, en un conjunto de sprites compuesta tienes que ir leyendo de memoria dicho conjunto e ir posicionando los sprites uno a uno, mucho más complejo y lento, te puedes esperar ralentizaciones donde no las hay con el método del tamaño fijo.

Eso lo podrás hacer en juego RPG o donde el rendimiento no sea crucial. En un arcade hay que buscar más velocidad y equilibrio con el uso de la memoria para acelerar ciertos procesos.

Y sí, los gráficos son así. Nuestro grafista usa mucho el usar tiles para bordear, es que tiene que ser así, si no queda raro, o muy pequeño, o con borde feo, o puede que incluso la parte interior se use en otros sitios y le cambies sólo el borde.

darksch escribió:Estás obviando lo más obvio. Realización. Mientras hacer una matriz bidimensional de un tamaño es lo que casi siempre se usaba por motivos obvios, el componer sprites de la manera que dices requiere que, cada fotograma, sea una composición en sí misma de multitud de sprites de distintos tamaños.

¿Tú sabes exactamente el coste que tiene eso?. Pues para empezar tienes que hacerte un editor de sprites específico para hacer dicha composición. Luego tienes que generar tu propia estructura que es más complicado de hacer, además de más lento, pues mientras en una matriz bidimensional de tamaños iguales indicas sólamente el ancho y alto (2 bytes) y autogeneras fácil y rápidamente, en un conjunto de sprites compuesta tienes que ir leyendo de memoria dicho conjunto e ir posicionando los sprites uno a uno, mucho más complejo y lento, te puedes esperar ralentizaciones donde no las hay con el método del tamaño fijo.

Eso lo podrás hacer en juego RPG o donde el rendimiento no sea crucial. En un arcade hay que buscar más velocidad y equilibrio con el uso de la memoria para acelerar ciertos procesos.

Y sí, los gráficos son así. Nuestro grafista usa mucho el usar tiles para bordear, es que tiene que ser así, si no queda raro, o muy pequeño, o con borde feo, o puede que incluso la parte interior se use en otros sitios y le cambies sólo el borde.

Hablamos de capcom, no de los dos chavales que hicieron el legend. Está claro que optaron por emplear un algoritmo que automatice el uso de sprites a cascoporro, porque claro, hay fuerza bruta para liarse por sprites por un tubo, pero al final tienes que reducir el número de personajes porque si no te pasa esto:

http://www.baddesthacks.net/forums/down ... 2634c4babb


Y el mayor fallo ni siquiera es la optimización del uso de los sprites, sino configurar la obsel para emplear tamaños de 8x8 y 16x16, en lugar de 16x16 y 32x32 (aquí no hay excusa de tiempos de desarrollo)... pero es que aún digo mas, los tamaños ideales habrían sido de 16x32 y 32x16, aunque ahí no le vamos a meter caña a capcom porque seguramente no estaría ni documentado.

Pero para el resto si que se puede criticar. La excusa no puede ser nunca que así es que se tardaría mas de 6 meses en hacer el juego... pues pones a un tío mas en el equipo y que se encargue el, que de nuevo, hablamos de capcom, no de un grupito amateur de dos personas, como en otros casos.

A cascoporro no, rendimiento.

Esos tamaños son los que también se usan en el Arcade. La forma en que se diseñan los personajes es lo que tiene. Si usas tamaños mayores vas a desperdiciar muchísima memoria. Imagina para pintar un puño que te sobresale en algún fotograma usar un sprite de ese tamaño.
Pilla rips de sprites de los arcades y verás como se hacen, en cuadrados pequeños para aprovechar la memoria. ¿Sabes quién no lo hacía así?, SNK, y mira lo que ocupan los cartuchos de NeoGeo.

@Señor Ventura Precisamente por ser Capcom y la experiencia en juegos de ese estilo igual estamos dejando de tener en cuenta cosas que ellos si y que nosotros no sabemos. Pueden tener sus motivos.

@varios , yo asumo que cuando un profesional de cualquier sector hace su trabajo, y no lo hace todo lo mejor que se puede hacer, se debe a dos motivos básicamente:

1- No sabe hacerlo mejor.
2- La relación calidad/coste del trabajo es aceptable para las dos partes.

¿Que quiero decir con la segunda opción?. Muy fácil, dedicar muchas horas mas para perfeccionar un trabajo(en este caso un videojuego) no sale a cuenta. La función de Capcom o de cualquier otro, no era aprovechar la SNES al 100% de sus capacidades con los juegos, sino hacer juegos lo suficientemente buenos como para que el esfuerzo que le dedicas al hacerlo salga rentable, y así poder dedicarte a otro proyecto.

Se trata de ganar dinero, no de aprovechar la máquina al 100%.

Además, la historia nos demuestra, que teniendo un nombre de franquicia potente en la época, era razón mas que suficiente para vender miles de copias, y casualmente, muchas de esas franquicias potentes tienen videojuegos que dan pena, como suele ser en muchos casos la adaptación de películas taquilleras a las consolas.

@aranya

Estoy plenamente de acuerdo contigo, y añado que a los desarrolladores les gustará trabajar siempre con holgura, pudiéndose realizar la optimización más completa de las consolas siempre al final de la vida de éstas.

Prueba de ello era el caso de Capcom, y de la época en sí, cuando las thirds disponían de placas arcade propias, en las que solían volcar a sus equipos principales de desarrollo, y no tanto en las consolas o sistemas domésticos, en donde habrían trabajado de forma más limitada e incomoda. Para esto último destinaban a otros grupos, o incluso licenciaban a algunas firsts de cada sistema; como pasó con Sega, desarrollando o portando algunos juegos de Capcom a sus consolas.

Un desarrollador comercial, que se debe a una empresa y a una serie de obligaciones, no puede siquiera comprometerse a portear un juego fuera de su zona de confort o control, y mucho menos dedicarse a optimizar y a aprovechar sistemas, si estos le son desconocidos o altamente tediosos, y menos si está acostumbrado a trabajar a placer en placas específicas para su trabajo.

Hasta es posible que les duela tener que hacer recortes a sus obras por culpa de una consola limitada. Una cosa es un desarrollador artístico, y la otra un desarrollador meramente técnico, que le da igual lo que se pierda mientras el máximo posible de números y valores de rendimiento quepan en el cartucho.

Estoy siguiendo todos esos datos tecnicos con atencion,como sabeis,que maravilla,
dejadme haceros unas preguntas que veo que sabeis de esto.

creeis que puede ser cierto que Richard Alpin dumpeara las Eprom de la PCB de Final Fight para su version Amiga?
o esto no puede ser?,el comenta que no tenia absolutamente nada y que el solo realizo esos dumpeos con un lector de Eproms casero...en el 1990 ,no se...supongo que puede ser ¿que opinais?

en FinalFight de SFC redibujo todo?o solo algunos Sprites?,por ejemplo en Strider de Megadrive se redibujo a Hiryu,con buenos resultados"imho",es comun rehacerlo todo?o es mas comun utilizar los graficos del Arcade para una Conversion?

cuando se hace una conversion de 68000 a 68000 es mas facil?,yo creia que si,pero me encuentro con versiones mucho mejores que no comparten procesador,ejemplo seria Sunset Riders de Megadrive Vs Super Nes,
la MD tiene la CPU del Arcade pero a mi no me parece ni la mitad de buena que la version Snes.

otro ejemplo,Zero Wing Megadrive vs Zero Wing Pc engine CD,el de PCE es bueno pero el de Megadrive es maravilloso y tremendamente fiel,no creo que rehiceran demasido en estas versiones ¿que opinais?no seria un trabajo terrible rehacer todo?.

aranya escribió:@varios , yo asumo que cuando un profesional de cualquier sector hace su trabajo, y no lo hace todo lo mejor que se puede hacer, se debe a dos motivos básicamente:

1- No sabe hacerlo mejor.
2- La relación calidad/coste del trabajo es aceptable para las dos partes.

¿Que quiero decir con la segunda opción?. Muy fácil, dedicar muchas horas mas para perfeccionar un trabajo(en este caso un videojuego) no sale a cuenta. La función de Capcom o de cualquier otro, no era aprovechar la SNES al 100% de sus capacidades con los juegos, sino hacer juegos lo suficientemente buenos como para que el esfuerzo que le dedicas al hacerlo salga rentable, y así poder dedicarte a otro proyecto.

Se trata de ganar dinero, no de aprovechar la máquina al 100%.

Además, la historia nos demuestra, que teniendo un nombre de franquicia potente en la época, era razón mas que suficiente para vender miles de copias, y casualmente, muchas de esas franquicias potentes tienen videojuegos que dan pena, como suele ser en muchos casos la adaptación de películas taquilleras a las consolas.

Intentan aprovechar lo que se puede en el tiempo que tienen. Pero hay muchos actores, por ejemplo (es un ejemplo nada más) si tienen para poner un tope de 10 sprites por personaje, algunos igual necesitan sólo 8 porque son más pequeños. Es un tema de diseño y no que pueda poner 10 y esos 2 que sobran no se usan en los jugadores 1P y 2P porque hay momentos que se usan en los enemigos. Lo mismo que en un juego 3D hay personajes que usan más polígonos que otros o hay fases con más detalles o colorido que otras.

Yo entiendo y comparto el entusiamo de Señor Ventura pero no tanto las críticas a Capcom en su labor en Snes. Con Sega ni siquiera se dignaba a programar y luego hay que ver cómo vendía licencias para programar en ordenadores y les importaba una mierda que fuera desastroso. Los usuarios de Snes salieron más que bien parados teniendo en cuenta estas circunstancias.

En el caso del FF siendo un cartucho de solo 8 megas y siendo de las primeras hornadas de Snes se comprende que la cosa no diera para mucho más y que el juego sufriera recortes. Se ve que Nintendo para el Strifa apretó más las clavijas a Capcom ya que ese sí que era un port estratégico de verdad.

El FF de Snes es un port más que digno que capta muy bien la esencia del arcade y que técnicamente impresionaba en su momento. Tú lo veías en vídeos promocionales y para ti era el arcade. Cosa que no podrían decir los usuarios de Amiga, por ejemplo, con el port demencial que sufrieron.

gaditanomania escribió:El FF de Snes es un port más que digno que capta muy bien la esencia del arcade y que técnicamente impresionaba en su momento. Tú lo veías en vídeos promocionales y para ti era el arcade. Cosa que no podrían decir los usuarios de Amiga, por ejemplo, con el port demencial que sufrieron.

A mí es que directamente me vendió la consola el FF, en menos de un segundo (literal):
https://youtu.be/3JD8jYgwcX8?t=17

Luego bajona, por no poder jugar a dobles, pero bueno... consiguieron lo que querían.

Puf pero es que máquina aprovechada al 100% no existe, decidme una.

Pero en concreto Capcom con su experiencia en el género y que no se puede decir precisamente que fuera mala en SNES en concreto, seguro que es de los que mejor partido le sacaba bajo las mismas condiciones que sus competidoras. Porque bueno, buscad otros beat'em up de SNES de otras compañías para comparar.

Para desaprovechados, los ordenadores 8 y 16 bit salvando al C64 y Spectrum que aunque daba para más, ya es con cosas muy arcanas.

@darksch , hay máquinas que deben de estar cerca de ser aprovechadas 100%, si tuvieron popularidad y años, puede ser un buen indicativo.

Para mí, la NES, la GB o la Psx son claros ejemplos.

emerald golvellius escribió:Estoy siguiendo todos esos datos tecnicos con atencion,como sabeis,que maravilla,
dejadme haceros unas preguntas que veo que sabeis de esto.

creeis que puede ser cierto que Richard Alpin dumpeara las Eprom de la PCB de Final Fight para su version Amiga?
o esto no puede ser?,el comenta que no tenia absolutamente nada y que el solo realizo esos dumpeos con un lector de Eproms casero...en el 1990 ,no se...supongo que puede ser ¿que opinais?

en FinalFight de SFC redibujo todo?o solo algunos Sprites?,por ejemplo en Strider de Megadrive se redibujo a Hiryu,con buenos resultados"imho",es comun rehacerlo todo?o es mas comun utilizar los graficos del Arcade para una Conversion?

cuando se hace una conversion de 68000 a 68000 es mas facil?,yo creia que si,pero me encuentro con versiones mucho mejores que no comparten procesador,ejemplo seria Sunset Riders de Megadrive Vs Super Nes,
la MD tiene la CPU del Arcade pero a mi no me parece ni la mitad de buena que la version Snes.

otro ejemplo,Zero Wing Megadrive vs Zero Wing Pc engine CD,el de PCE es bueno pero el de Megadrive es maravilloso y tremendamente fiel,no creo que rehiceran demasido en estas versiones ¿que opinais?no seria un trabajo terrible rehacer todo?.

En la época, las conversiones de ordenador (en Europa) se solían hacer a la brava, o redibujando todo a saco (Los Double Dragon de Amstrad o Spectrum hechos en España por Animagic), o extrayendo los gráficos de las PCB's, o incluso sin tener la recreativa, teniendo un VHS de todo el juego, calcando encima de la tele con la pausa puesta...

Sobre lo del procesador a la hora de las conversiones, depende. En los ordenadores de 8 bits, se hizo mucho con el trio Amstrad, Spectrum y Msx, al compartir procesador y "hasta cierto punto" arquitectura, se programaban pero pensando en la plataforma más floja, en este caso, el spectrum. En consolas, también se hizo, sobretodo entre GameBoy, GameGear y Master System, por ejemplo con Lemmings, o Los Pitufos.

Pero convirtiendo desde una recreativa con mucha más chicha, y una arquitectura mucho más rara...probablemente debían hacer muchas cosas de cero...y eso suponiendo que tuvieran acceso al código original.

@kusfo79 , para mí fue un desastre lo que hacían. Yo antes de la MS tuve un MSX, y me "comí" un montón de ports marranos de Spectrum, hasta el punto de pensar que mi MSX era como un Spectrum, y con la llegada de Internet quedarme con cara de tonto.

En algunos ports, encima el rendimiento era peor.
Era un desastre.

kusfo79 escribió:

emerald golvellius escribió:Estoy siguiendo todos esos datos tecnicos con atencion,como sabeis,que maravilla,
dejadme haceros unas preguntas que veo que sabeis de esto.

creeis que puede ser cierto que Richard Alpin dumpeara las Eprom de la PCB de Final Fight para su version Amiga?
o esto no puede ser?,el comenta que no tenia absolutamente nada y que el solo realizo esos dumpeos con un lector de Eproms casero...en el 1990 ,no se...supongo que puede ser ¿que opinais?

en FinalFight de SFC redibujo todo?o solo algunos Sprites?,por ejemplo en Strider de Megadrive se redibujo a Hiryu,con buenos resultados"imho",es comun rehacerlo todo?o es mas comun utilizar los graficos del Arcade para una Conversion?

cuando se hace una conversion de 68000 a 68000 es mas facil?,yo creia que si,pero me encuentro con versiones mucho mejores que no comparten procesador,ejemplo seria Sunset Riders de Megadrive Vs Super Nes,
la MD tiene la CPU del Arcade pero a mi no me parece ni la mitad de buena que la version Snes.

otro ejemplo,Zero Wing Megadrive vs Zero Wing Pc engine CD,el de PCE es bueno pero el de Megadrive es maravilloso y tremendamente fiel,no creo que rehiceran demasido en estas versiones ¿que opinais?no seria un trabajo terrible rehacer todo?.

En la época, las conversiones de ordenador (en Europa) se solían hacer a la brava, o redibujando todo a saco (Los Double Dragon de Amstrad o Spectrum hechos en España por Animagic), o extrayendo los gráficos de las PCB's, o incluso sin tener la recreativa, teniendo un VHS de todo el juego, calcando encima de la tele con la pausa puesta...

Sobre lo del procesador a la hora de las conversiones, depende. En los ordenadores de 8 bits, se hizo mucho con el trio Amstrad, Spectrum y Msx, al compartir procesador y "hasta cierto punto" arquitectura, se programaban pero pensando en la plataforma más floja, en este caso, el spectrum. En consolas, también se hizo, sobretodo entre GameBoy, GameGear y Master System, por ejemplo con Lemmings, o Los Pitufos.

Pero convirtiendo desde una recreativa con mucha más chicha, y una arquitectura mucho más rara...probablemente debían hacer muchas cosas de cero...y eso suponiendo que tuvieran acceso al código original.

Por las entrevistas que he leido en la version Amiga de Final Fight Capcom no colaboro para nada.
el programador decidio por su cuenta Dumpear los graficos,no se...,lo encuentro muy heavy.

conseguir "por tu cuenta"la PCB del juego en esa epoca...,hoy dia guay,pero en 1990 ponerte a "conseguir" una PCB con un precio que tiraria de espaldas para dumpear graficos, de todos modos un trabajo que realizo una sola persona...asi salio el juego.

otra duda que tengo es por que en Super Famicom recortaron hasta las introducciones mas escuetas...osea Cody y Haggar no dan ni un paso mas de la cuenta,desaparece la pantalla y aparecemos en el otro punto...,en las demas versiones los personajes avanzan,rompen una puerta,son atrapados por otro personaje y llevados por el cuello etc,imagino que esto es para ahorrar memoria,pero luego se dejan dentro del cartucho el escenario inacabado de La Factoria con su musica completa,no lo entiendo.

comprendo que al no ejecutarse no se trabaja con eso,pero me parece un poco chapuza,si vas apretado y quitas ciertas cosas dejar eso ahi.

emerald golvellius escribió:comprendo que al no ejecutarse no se trabaja con eso,pero me parece un poco chapuza,si vas apretado y quitas ciertas cosas dejar eso ahi.

Es que antes hacían muchas chapuzas, lo que pasa es que no había el mismo nivel de control e información que hay ahora. Por eso cuando algunas veces en este foro se habla de que hoy en día los juegos son una mierda, que es un timo, etc, etc, y que antes era todo mucho mejor, pues yo no estoy de acuerdo con ellos.

aranya escribió:@darksch , hay máquinas que deben de estar cerca de ser aprovechadas 100%, si tuvieron popularidad y años, puede ser un buen indicativo.

Para mí, la NES, la GB o la Psx son claros ejemplos.

Justo esas que mencionas si incluso casi más de lo que se esperaría de ellas.

Y no nos equivoquemos, las consolas populares por lo general se han aprovechado bastante al límite, había mucha competencia en vender cada uno su juego. Pero si en aprovechar ese 10% extra que le podrías sacar el coste se te va un 30%, pues no se hace está claro.

darksch escribió:A cascoporro no, rendimiento.

Esos tamaños son los que también se usan en el Arcade. La forma en que se diseñan los personajes es lo que tiene. Si usas tamaños mayores vas a desperdiciar muchísima memoria. Imagina para pintar un puño que te sobresale en algún fotograma usar un sprite de ese tamaño.
Pilla rips de sprites de los arcades y verás como se hacen, en cuadrados pequeños para aprovechar la memoria. ¿Sabes quién no lo hacía así?, SNK, y mira lo que ocupan los cartuchos de NeoGeo.

Es que si hablamos de como hacer un final fight mejor con los mismos 8 megabits, entonces ahí no puedo decir nada. Obviamente cuanto mas pequeño es el sprite, menos pixels vacíos dejas que también ocupan memoria.

Yo hablaba de capacidad real, siendo realistas. Cuentas con un buen ancho de banda, y unos límites para almacenar sprites tanto en rom como en vram mas que suficientes. La pega aquí es la tasa de relleno por scanline, y la cpu que tengas para mover los enemigos resultantes.

No es que lo haya desglosado muy bien, pero según las cifras todo encaja bastante, y tu sabes que en cuestión de dibujar (que no mover), poco margen de equivocación te queda, porque se puede precalcular perfectamente.

varios escribió:@Señor Ventura Precisamente por ser Capcom y la experiencia en juegos de ese estilo igual estamos dejando de tener en cuenta cosas que ellos si y que nosotros no sabemos. Pueden tener sus motivos.

En concreto el port del final fight de snes fué un episodio bastante movidito. Me suena que capcom quería meter un cartucho de 16 megas, y nintendo dijo que nanai.

Me parece increíble que le puedas decir a nadie que tamaño deben tener sus juegos, pero me suena que la historia iba por ahí, y entonces capcom se mosqueó y se dejó ir con el juego, saliendo mal acabado, como ya sabemos todos.

@Señor Ventura

Pues como hubiera pasado con el Strifa de llevar 8 megas, que hubieran tenido que sacrificar cosas como personajes. Quitar al menos 2 personajes seleccionable y 2 jefes. Eso o recortar más en gráficos.

Es que sigo diciendo que no es que lo hicieran mal con el FF. Es que no tenían mucho mas de donde rascar. ¿Que habia margen de hacerlo mejor con 8 megas? Puede ser. Pero no mucho mejor. Tenian que recortar sí o sí.

gaditanomania escribió:@Señor Ventura

Pues como hubiera pasado con el Strifa de llevar 8 megas, que hubieran tenido que sacrificar cosas como personajes. Quitar al menos 2 personajes seleccionable y 2 jefes. Eso o recortar más en gráficos.

Es que sigo diciendo que no es que lo hicieran mal con el FF. Es que no tenían mucho mas de donde rascar. ¿Que habia margen de hacerlo mejor con 8 megas? Puede ser. Pero no mucho mejor. Tenian que recortar sí o sí.

Yo quito fases de Bonus y meto como sea ese escenario que ya estaban trabajando en el y tenian hasta la musica,
meto los 3 personajes y el modo 2 player,las fases de Bonus del coche y de los cristales deben ocupar...,
lo que sea menos lo que optaron por hacer.

mirado de forma mas realista,fuera los Bonus y dentro Guy y el modo 2 player,pasando del stage de rolento si eso...

@aranya
Solían ir mal por que no usaban ni tan solo los sprites por hardware ni otras mandangas del MSX

@emerald golvellius
De hecho, el Richard Aplin este hizo otro Double Dragon para Amstrad (otra versión), en que usó sus gráficos ripeados de la versión de Atari St de Double Dragon, y los convirtió a Amstrad CPC a saco. Era todo muy pedestre:
Versión Double Dragon Animagic:


Versión Double Dragon Richard Aplin:


Eso si, si queréis empaparos de como iba el negocio en esa época en Europa, leeros el libro de Bob Pape sobre sus aventuras haciendo la conversión de R-Type para Spectrum:
It's behind you: The Making of a videogame

@Señor Ventura
Lo de los tamaños de memoria era el pan nuestro de cada día en la época. De hecho, por ejemplo, los que convirtieron el Golden Axe para mega se quejaron de que Sega les asignó solo 4 MB para hacer la conversión (ya desde el inicio del proyecto), y fliparon con ello.
En el Final Fight, el hecho de que las animaciones estén recortadas, pero haya todo un escenario sin usar, se puede entender como que no fué hasta bien adelante que se dieron cuenta que el escenario entero no iba a caber, y ya no se dedicaron a cambiar las animaciones again.

Señor Ventura escribió:Es que si hablamos de como hacer un final fight mejor con los mismos 8 megabits, entonces ahí no puedo decir nada. Obviamente cuanto mas pequeño es el sprite, menos pixels vacíos dejas que también ocupan memoria.

Yo hablaba de capacidad real, siendo realistas. Cuentas con un buen ancho de banda, y unos límites para almacenar sprites tanto en rom como en vram mas que suficientes. La pega aquí es la tasa de relleno por scanline, y la cpu que tengas para mover los enemigos resultantes.

No es que lo haya desglosado muy bien, pero según las cifras todo encaja bastante, y tu sabes que en cuestión de dibujar (que no mover), poco margen de equivocación te queda, porque se puede precalcular perfectamente.

Ya, pero el coste es un factor decisivo. Ahí está el FF-CD, que es una MD con un CD poniendo el almacenamiento y en principio hicieron el juego tal y como se quiso, con todas las animaciones. Que se podría haber rascado un poco más haciendo el sistema de mezclar sprites al milímetro de distintos tamaños, y mira que MD los tiene en 16 tamaños distintos desde 8x8 hasta 32x32 en cualquier combinación, y encima un Motorola que seguro le pesaba menos gestionar ese sistema de dibujado, bueno sí, pero si por quitar algunos flickeos de sprites o poner algún enemigo más (la jugabilidad está perfectamente ajustada a lo que sale) aumentas mucho el coste de desarrollo, pues no se hace.

Por lo que en cartucho, si encima de lo mencionado, también aumentas el coste de venta, o disminuyes tu beneficio por copia, menos aún.

@kusfo79 , gracias por la explicación.

A ver si me pongo con el FFCD, después de haber estado jugando mucho a la versión Snes me apetece volver a jugarlo. He disfrutado mucho la versión Snes.

@kusfo79 R.Alpin el matarife del 16 Bits,aunque oye...una persona sola haciendo eso en el tiempo que le pusieran como limite...quizas hasta es un genio.

lo del R-Type lo lei hace tiempo,en la epoca me hacia gracia cuando amigos me decian que el R-Type de Amiga era increible...que era el Arcade...,tras un ligero analisis pensaba"si...el primer Stage quizas se lo trabajaron,llegas al 3 y te desinflas",tenian prisa para trincar el dinero de la Abuela como decia el propio Alpin.

@aranya cuando pruebes bien el FF de MCD comentame a ver si ves ahi una falta de Frames,sobre todo fijate al pillar tuberias o espadas,y fijate en los enemigos al ser impactados,videalo bien hermanito videalo bien.

@emerald golvellius , perfecto, estaré atento. Aprovecharé para jugar a la MS también, que este mes toca la MS con el Land of Ilusion en otro hilo.
Aprovecho por si alguien más se quiere apuntar.

aranya escribió:@emerald golvellius , perfecto, estaré atento. Aprovecharé para jugar a la MS también, que este mes toca la MS con el Land of Ilusion en otro hilo.
Aprovecho por si alguien más se quiere apuntar.

Creo que te volara la mente,el juego es brutal,muy bueno y veras cosas que en la version SNES ni soñando...,
me compre un Mega CD por ese juego y el Road Avenger practicamente,pero se nota falta de "algo",
sin duda es la mejor version accesible,prueba si puedes la version Japonesa o veras a Poison y Roxy con mini Shorts.

una cosa que si recuerdo que me impacto de FF MCD es que fue de los primeros juegos que disfrute en TV grande y con RGB,y sinceramente ahi se nota una falta de color grande,hay un Hack de color pero nunca lo he probado.

@emerald golvellius , yo el hack lo probé en emulador, antes no tenía el MCD. Desde hace no mucho lo tengo, así que a ver si juego un poquito.
Del emulador recuerdo un poco el flickering, que es muy llevadero, y sobretodo los 2 players. Lo jugué con mi hermano, y me apetecía más una versión de consola que el arcade, ya que las consolas son lo que me gusta jugar.

Yo lo jugaré por RGB y en CRT de 29". La Snes la jugué por AV, ya que aún no tengo el cable.

aranya escribió:@emerald golvellius , yo el hack lo probé en emulador, antes no tenía el MCD. Desde hace no mucho lo tengo, así que a ver si juego un poquito.
Del emulador recuerdo un poco el flickering, que es muy llevadero, y sobretodo los 2 players. Lo jugué con mi hermano, y me apetecía más una versión de consola que el arcade, ya que las consolas son lo que me gusta jugar.

Yo lo jugaré por RGB y en CRT de 29". La Snes la jugué por AV, ya que aún no tengo el cable.

Ese juego tiene una forma de color diferente,yo creo que utilizaron algo diferente,se ve diferente que por ejemplo SOR2,
es como ver uno de aquellos juegos de NECPC88 en la que los sombreados creaban tonalidades para aprovechar mejor la paleta...

darksch escribió:Hombre sí, el MIDI bien hecho vale que suena bien y queda chulo eso de que lo haga el chip.

El chip interno del X-68000 (Yamaha YM2151, mismo que el de la CPS 1) genera puro FM, y luego tiene un Okidata MSM6258 que reproduce un canal ADPCM. Para el sonido "MIDI" con varias voces a la vez son necesarios módulos cómo los Roland SC-55 y MT-32.

A tenor del tema, quisiera llamar la atención sobre esto:





Conversión, que no emulación genérica e impersonal, del Castlevania aparecido en el X-68000 totalmente adaptado a las capacidades de PlayStation (resolución, sonido, etc), en la cual están disponibles todas las OST con el módulo interno FM, MIDI, etc; incluso hay una banda sonora totalmente nueva exclusiva para el modo "Arranged", en el cual manejamos a un Simon muy jevi con el pelo teñido de rosa, y una dificultad mucho más suavizada y balanceada (el modo original está por defecto en HARD):



Simon's theme en nivel de calidad Dios:

https://www.youtube.com/watch?v=phdJk7a18Cg&index=12&list=PL03566810DF7CFE6D

Aiins lo que se perdieron los Nintenderos más cerrados, nada menos que la SNES 2

@emerald golvellius no te rayes mucho: Final Fight CD tiene jodida la cadencia de los combos y golpes con objetos, es mucho más lento que el ARCADE y otras versiones en ese sentido, genera diversos "extraños", sobre todo en versión PAL.

Lo conozco. Pero el tema iba sobre MIDI. Por si el emulador lo sacaba o no.

@Sexy MotherFucker

Joder vaya diferencia de dificultad entre el Castlevania original de X68k y el remake de PSX. Ese tipo de remakes dan gusto. Jugabilidad mejorada, gráficos remozados, melodías más cañeras...genial vamos.