Mega Final Fight en MegaDrive!

chinitosoccer escribió:Al final parece que no van a ser posibles mas de 4 enemigos en pantalla (6 si, pero a 30fps) , 4 enemigos y 60fps es lo mismo que pone el Final FightCD....vaya, resulta que los de Sega no eran tan mancos...exprimiendo MegaCD en 1993! (que no la MD pelada).

Y el de MegaCD estaba programado en assembler y no en C como éste. Además de tener que lidiar con el hardware del addon y la comunicación con el sistema base.

Sería curioso ver si se podría llegar más allá utilizando assembler y sin el uso del SGDK (aunque hay que ser valiente para intentarlo).

chinitosoccer escribió:Al final parece que no van a ser posibles mas de 4 enemigos en pantalla (6 si, pero a 30fps) , 4 enemigos y 60fps es lo mismo que pone el Final FightCD....vaya, resulta que los de Sega no eran tan mancos...exprimiendo MegaCD en 1993! (que no la MD pelada).

¿4 enemigos a 2 player? ¿Por curiosidad cuantos ponia SNES?

naxeras escribió:

chinitosoccer escribió:Al final parece que no van a ser posibles mas de 4 enemigos en pantalla (6 si, pero a 30fps) , 4 enemigos y 60fps es lo mismo que pone el Final FightCD....vaya, resulta que los de Sega no eran tan mancos...exprimiendo MegaCD en 1993! (que no la MD pelada).

¿4 enemigos a 2 player? ¿Por curiosidad cuantos ponia SNES?

Depende.

El hack del final fight 2 pone 5 enemigos a 2 jugadores. Tiene problemas de flickering, pero también usa los sprites de forma poco eficiente, cosa que incrementa ese inconveniente.

Eso si, sin problemas de rendimiento pese a ser códigos por lo visto poco optimizados, al menos el del final fight 3, según he leído.

Señor Ventura escribió:

naxeras escribió:

chinitosoccer escribió:Al final parece que no van a ser posibles mas de 4 enemigos en pantalla (6 si, pero a 30fps) , 4 enemigos y 60fps es lo mismo que pone el Final FightCD....vaya, resulta que los de Sega no eran tan mancos...exprimiendo MegaCD en 1993! (que no la MD pelada).

¿4 enemigos a 2 player? ¿Por curiosidad cuantos ponia SNES?

Depende.

El hack del final fight 2 pone 5 enemigos a 2 jugadores. Tiene problemas de flickering, pero también usa los sprites de forma poco eficiente, cosa que incrementa ese inconveniente.

Eso si, sin problemas de rendimiento pese a ser códigos por lo visto poco optimizados, al menos el del final fight 3, según he leído.

A ver yo me referia al final fight comercial la verdad porque es el que tendra un IA similar y estara limitado para no parpadear.

Si eres tolerante con los parpadeos pues puedes meter muchos sprites pero precisamente por eso se limita.

Yo no termino de entender el limite de estas consolas, porque hay como limite en pantalla, limite por scanline y al final es dificil saber cuantos sprites mueve tal juego o tal otro sin parpadeos.

naxeras escribió:A ver yo me referia al final fight comercial

Si, pero es que este mega final fight no es comercial tampoco.

naxeras escribió:Si eres tolerante con los parpadeos pues puedes meter muchos sprites pero precisamente por eso se limita.

Yo no termino de entender el limite de estas consolas, porque hay como limite en pantalla, limite por scanline y al final es dificil saber cuantos sprites mueve tal juego o tal otro sin parpadeos.

Se puede jugar sin complejos con los parpadeos, pero final fight 2 es una exageración.

Puedes emplear mejor los sprites para dibujar lo mismo usando menos tiles, y por lo tanto no sobrecargando el límite de sprites por scanline... o puedes emplear métodos por software como parpadeos controlados según la prioridad de los personajes (quien se dibuja por encima de que otro personaje)... o la mas eficiente: no dibujando sprites que queden parcial o totalmente tapados (esta es la que mas cpu debe requerir).

Cuantos muñecos en total pone el de Snes y de mega CD, en este serían 4+2 a dobles lo que daria un máximo de 6 aunque hay opción de hasta 8, es una burrada.

Señor Ventura escribió:Si, pero es que este mega final fight no es comercial tampoco.

Ya lo sé yo no he dicho que lo sea, sólo pregunte que cuantos pone el FF de SNES nada más y se me ha contestado con FF2, no entiendo por que, de todas formas lo he buscado y pone 3 mas el player y sin posibilidad a 2 players por si alguien mas se lo preguntaba.

Señor Ventura escribió:Se puede jugar sin complejos con los parpadeos, pero final fight 2 es una exageración.

Claro yo creo que por eso lo limitaron, que algo parpadee no mola, ya pasa en el FF de SNES que barriles no dan objetos si hay enemigos en pantalla supongo que por esto mismo, lo que no sabia era el limite de enemigos porque jugando pues no me pongo a contarlos.

Señor Ventura escribió:Puedes emplear mejor los sprites para dibujar lo mismo usando menos tiles, y por lo tanto no sobrecargando el límite de sprites por scanline... o puedes emplear métodos por software como parpadeos controlados según la prioridad de los personajes (quien se dibuja por encima de que otro personaje)... o la mas eficiente: no dibujando sprites que queden parcial o totalmente tapados (esta es la que mas cpu debe requerir).

Pero hay un limite y una razon por la que no se hizo así y es el tamaño de la VRAM. Partiendolo en mas tiles al animar reusas tiles y si no lo partes pues tienes que cada animacion guardarla completa y llenas la VRAM, tambien esta el tamaño del cartucho, pero vamos el juego este de mega usara el maximo cartucho disponible nada mas verlo.

El resto de opciones chupan la CPU que no creo que en un juego de estas caracteristicas vaya muy sobrado precisamente a no ser que hagas lo muñecos monguer como pasa en algunos juegos de las consolas de 16 bits vs arcade

naxeras escribió:Pero hay un limite y una razon por la que no se hizo así y es el tamaño de la VRAM.

Si eso fuese así, los hacks no funcionarían por las buenas.

naxeras escribió:Partiendolo en mas tiles al animar reusas tiles y si no lo partes pues tienes que cada animacion guardarla completa y llenas la VRAM, tambien esta el tamaño del cartucho

No guardas las animaciones completas en la vram, sino solo el gráfico del frame a mostrar durante el frame actual.

Para el siguiente frame el cuadro de animación se borra, y se vuelve a escribir el gráfico que compone el siguiente cuadro de animación. La animación en un juego de estos actualiza el cuadro de animación cada 3, 4, 5 frames, o incluso mas.

No lo parece porque todo sucede muy rápido, pero van sobraditas para ser el hardware que son. Sus limitaciones suelen ser otras.

Existe el hack(supongo que fastrom),con dos players y 3 enemigos.

estoybien escribió:Estoy de acuerdo en que todavía hay un componente artesanal al hacer conversiones y que todavía arrastran por ejemplo el problema de acceso al código fuente. Y tienen que hacerlo todo: código, gráficos, música, planificación, depuración, ingeniería inversa, que muchas veces lo hace uno solo.

No le quito mérito a los programadores actuales pues están consiguiendo cosas antes impensables como el wolfenstein de gasega, pero la revolución tecnológica es impresionante en casi todos los sentidos. Impresionante que de verlo antaño alucinamos pepinillos. Lo que se hace nunca se han podido hacer tan deprisa, y lo hacen en ratos libres de su vida y si tardan 4 años en sacarlo no pasa nada (a no ser que los patreons empujen)....

Etcétera etcétera

Estoy completamente de acuerdo en qué hoy día las herramientas y la tecnología en general han evolucionado mucho no, muchísimo con respecto a aquélla época.
Estamos a años luz.

Pero en cambio sigo pensando que es más importante "quién" las utiliza, y el tiempo que le dedica a ello.
Y antaño eran programadores profesionales trabajando 24/7.

No es lo mismo un juego hecho por muchos programadores profesionales que por un desarrollador amateur, por mucho tiempo que este tarde en terminarlo, que por cierto como norma general no eran precisamente cuatro gatos los encargados de hacer juegos sino más bien todo lo contrario , sobre todo en franquicias famosas, y ya que estamos en el hilo de Final Fight te animo a comprobar, por ponerte un simple ejemplo que venga al caso ,cuántas personas estuvieron involucradas en el port de SNES.
Te sorprenderas.

Proyectos dónde estén involucrados tan poca gente como comentas era una minoría.
En estudios 'pequeños' (en número de trabajadores) estilo Zyrinx o Treasure, tal vez.

Mira , se me viene a la mente ahora mismo el caso concreto de Alien Soldier y que al final su principal creador necesitó de ayuda de más compañeros para poder sacar el proyecto adelante en las fechas previstas y no pudo meter todo lo que tenía en mente.
Salió recortado respecto a lo que pensaba meter de primeras.
Los plazos de entrega me parece una limitación más grande que la tecnología/herramientas que poseían.
O incluso el tamaño de los cartuchos.

Siendo ya más actual, Cave Story, por ejemplo, fue un juego que su creador tardó varios años en hacerlo, cierto, y ha reconocido en entrevistas que fue aprendiendo sobre la marcha a desarrollar,

¿Cuánto tiempo crees que habrían tardado en hacerlo gente profesional del sector aún con herramientas más antiguas?
Nada, poquísimo tiempo, menos de lo que tarda el pato en intentar trollear un hilo de MD.

Un saludo.

Señor Ventura escribió:Si eso fuese así, los hacks no funcionarían por las buenas.

¿Quieres decir que el hack no solo desactiva el limite de enemigos? ¿Tambien reordena los tiles?, ¿lo has mirado en la VRAM? no lo sabia.

Señor Ventura escribió:No guardas las animaciones completas en la vram, sino solo el gráfico del frame a mostrar durante el frame actual.

¿Como? ¿Estas seguro? ¿recargas la VRAM en cada frame? pensé que tenian que estar en las tablas todas las animaciones, saque esa conclusión al ver un video del hack de G&G de mega que dice que para poder meter todos los fames de animacion del demonio rojo tuvo que partir en más tiles el demonio para asi meter todas las animaciones en la VRAM.

https://youtu.be/Gp2Q2Blj15w?si=v0kByPhmUpEyWJGM&t=386

¿No hay limite de animaciones entonces en las maquinas de 16bits?

mcfly escribió:Existe el hack(supongo que fastrom),con dos players y 3 enemigos.

EDITO: ¿Es este no?

https://www.youtube.com/watch?v=mL6eLjMjWsw

naxeras escribió:

Señor Ventura escribió:Si eso fuese así, los hacks no funcionarían por las buenas.

¿Quieres decir que el hack no solo desactiva el limite de enemigos? ¿Tambien reordena los tiles?, ¿lo has mirado en la VRAM? no lo sabia.

No, me refería a que si los FF fuesen como son porque alcanzan un límite, los hacks no habrían podido mostrar mas. Precisamente no modifican nada, ponen mas cosas en pantalla por las buenas.

naxeras escribió:¿Como? ¿Estas seguro? ¿recargas la VRAM en cada frame?

Si, así es como funciona.

Puedes guardar gráficos en vram que se usan muy recurrentemente, como balas, y cosas así, pero las animaciones no se guardan enteras, piensa que tienes que dejar espacio para dibujar los escenarios, y estas máquinas tienen solo 64KB de vram.

Eso no quita que no puedas guardar animaciones enteras en vram, pero no es lo mas eficiente. Los personajes de un final fight son muy grandes, no puedes guardar todas las animaciones de todos los personajes en memoria.

naxeras escribió:¿No hay limite de animaciones entonces en las maquinas de 16bits?

Si, hay límites. Por cada nuevo frame puedes transmitir varios KB's de información gráfica. Es mucho.

naxeras escribió:

Señor Ventura escribió:No guardas las animaciones completas en la vram, sino solo el gráfico del frame a mostrar durante el frame actual.

¿Como? ¿Estas seguro? ¿recargas la VRAM en cada frame? pensé que tenian que estar en las tablas todas las animaciones, saque esa conclusión al ver un video del hack de G&G de mega que dice que para poder meter todos los fames de animacion del demonio rojo tuvo que partir en más tiles el demonio para asi meter todas las animaciones en la VRAM.

https://youtu.be/Gp2Q2Blj15w?si=v0kByPhmUpEyWJGM&t=386

¿No hay limite de animaciones entonces en las maquinas de 16bits?

No, eso es una burrada.

Tienes un límite muy estricto en lo que puedes copiar a la VRAM entre el final de la última línea que se dibuja de la imagen anterior y el inicio de la primera de la siguiente.

En VRAM debes tener lo que vayas a dibujar en cada imagen, que es todo lo que se va a ver en pantalla.
A partir de ahí, y tras la carga inicial del nivel, puedes cambiar sólo un puñado de tiles de imagen a imagen, y ahí está el límite de las máquinas para poner muñecos grandes, no en moverlos por la pantalla. Por eso el Final Fight de Snes tiene esos marcazos, CAPCOM los usa para rascar tiempo para cargar los nuevos tiles de la siguiente imagen, que son sólo los que cambian por las animaciones de los personajes, nada más. Todo lo demás permanece en la VRAM, no se borra.

En los juegos VS, como el Street Fighter, todo el sprite de cada luchador cambia entre imagen e imagen, por eso la Snes va al límite cuando se podría pensar que 2 personajes no son tantos como los 4 o 5 de un beat em' up como el Final Fight. Pero, si te fijas, los muñecos de un beat 'em up están muchísimo menos animados y tienden a estar clonados.

En juegos con sprites más pequeños y frenéticos, como un Gunstar Heroes, mantienes en VRAM todas las animaciones posibles para mantener el rendimiento, pues no tienes la capacidad de mover toda esa cantidad de información entre imagen e imagen ni de blas. En este caso, todas las animaciones de los enemigos clónicos están en todo momento en memoria.

Hay que tener mucho cuidado sobre que información aceptas como buena en general, y más concretamente por estos lares.

Paprium escribió:Estoy completamente de acuerdo en qué hoy día las herramientas y la tecnología en general han evolucionado mucho no, muchísimo con respecto a aquélla época.
Estamos a años luz.

Pero en cambio sigo pensando que es más importante "quién" las utiliza, y el tiempo que le dedica a ello.
Y antaño eran programadores profesionales trabajando 24/7.

No es lo mismo un juego hecho por muchos programadores profesionales que por un desarrollador amateur, por mucho tiempo que este tarde en terminarlo, que por cierto como norma general no eran precisamente cuatro gatos los encargados de hacer juegos sino más bien todo lo contrario , sobre todo en franquicias famosas, y ya que estamos en el hilo de Final Fight te animo a comprobar, por ponerte un simple ejemplo que venga al caso ,cuántas personas estuvieron involucradas en el port de SNES.
Te sorprenderas.

Proyectos dónde estén involucrados tan poca gente como comentas era una minoría.
En estudios 'pequeños' (en número de trabajadores) estilo Zyrinx o Treasure, tal vez.

Mira , se me viene a la mente ahora mismo el caso concreto de Alien Soldier y que al final su principal creador necesitó de ayuda de más compañeros para poder sacar el proyecto adelante en las fechas previstas y no pudo meter todo lo que tenía en mente.
Salió recortado respecto a lo que pensaba meter de primeras.
Los plazos de entrega me parece una limitación más grande que la tecnología/herramientas que poseían.
O incluso el tamaño de los cartuchos.

Siendo ya más actual, Cave Story, por ejemplo, fue un juego que su creador tardó varios años en hacerlo, cierto, y ha reconocido en entrevistas que fue aprendiendo sobre la marcha a desarrollar,

¿Cuánto tiempo crees que habrían tardado en hacerlo gente profesional del sector aún con herramientas más antiguas?
Nada, poquísimo tiempo, menos de lo que tarda el pato en intentar trollear un hilo de MD.

Un saludo.

Siempre depende de la habilidad. Si hay medios porque hay que saber orquestarlos, si no los hay, porque hay que saber compensarlos. Detrás de ésto a veces hay chapuceo, horas extra no remuneradas, problemas...

El staff de final fight de snes según los créditos del juego:
1 planificador
1 música
5 programadores
5 diseñadores de objetos
5 diseñadores de fondos
2 special thanks
Juego de lanzamiento en 8 megabits y 5 meses de desarrollo creo. Eso sí, como dices gente que se dedica a ello, a jornada completa.

Tenían una experiencia y al final tener una especialización pues ayuda un montón a centrarte y a mejorar, aunque también complica más las cosas en el sentido de que el trabajo de unos depende del de los demás. Si lo haces todo tienes todo a tus espaldas, pero también mayor libertad creativa porque no dependes de otros. Todo tiene su cosilla.

Cave story estaría condicionado por el equipo de desarrollo, la máquina, también el presupuesto, un estudio de viabilidad, el formato y las fechas. Problemas diametralmente opuestos a los que tuvo su creador que lo hizo en años para Windows y sería complicado saber cómo le afectaría.

naxeras escribió:

Señor Ventura escribió:Si eso fuese así, los hacks no funcionarían por las buenas.

¿Quieres decir que el hack no solo desactiva el limite de enemigos? ¿Tambien reordena los tiles?, ¿lo has mirado en la VRAM? no lo sabia.

Señor Ventura escribió:No guardas las animaciones completas en la vram, sino solo el gráfico del frame a mostrar durante el frame actual.

¿Como? ¿Estas seguro? ¿recargas la VRAM en cada frame? pensé que tenian que estar en las tablas todas las animaciones, saque esa conclusión al ver un video del hack de G&G de mega que dice que para poder meter todos los fames de animacion del demonio rojo tuvo que partir en más tiles el demonio para asi meter todas las animaciones en la VRAM.

https://youtu.be/Gp2Q2Blj15w?si=v0kByPhmUpEyWJGM&t=386

¿No hay limite de animaciones entonces en las maquinas de 16bits?

mcfly escribió:Existe el hack(supongo que fastrom),con dos players y 3 enemigos.

EDITO: ¿Es este no?

https://www.youtube.com/watch?v=mL6eLjMjWsw

El hack que yo hablo,es para dos jugadores,colores de recreativa y personajes sin censura,sacados de la versión jap.

dr apocalipsis escribió:Hay que tener mucho cuidado sobre que información aceptas como buena en general, y más concretamente por estos lares.

Supongo que lo que tiene internet es que no sabes quién está detrás de una afirmación.

Si vas a un bar y el parroquiano de turno te explica cómo se suele manejar la VRAM en los beatemups de la SNES, lo más normal es que no le des mucha credibilidad

Como siempre (no sólo "por estos lares"), las afirmaciones de los expertos de barra de bar hay que cogerlas con pinzas. Por ejemplo, en este caso mejor preguntar a alguien que haya hecho algún beatemup para consolas retro, o al menos a alguien que haya hecho algún juego para ellas.

En Megadrive, por mucho avance en el SGDK, herramientas de todo tipo, software, ordenadores de la nasa y lo que sea que haya ahora, dudo que nadie pueda programar algo relativamente similar a un Thunderforce IV, Contra Hardcorps, Dynamite Headdy o ni siquiera un Musha Aleste (1990, 512kb)

Y como ya han mencionado, en la época estas producciones eran creadas por peña que no salía de la oficina, con la presión de una fecha límite (6 meses - 1 año como mucho) y demás cosas que no sabemos del ambiente de trabajo japonés.

PD: Ha salido un libro en inglés sobre la historia de Treasure y sus andaduras con la Mega (no se si hablan de juegos de Saturn y posteriores), hay algunas capturas de unas 20 páginas por ahi dando vueltas pero sería buenisimo que si alguien lo tiene recopile algo para ENTERARNOS de que tipo de brujerías hacía esa gente en MD.

Y estos juegos. Donde se pueden comprar?

mcfly escribió:El hack que yo hablo,es para dos jugadores,colores de recreativa y personajes sin censura,sacados de la versión jap.

Ok, ¿Serias tan amable de pasarme un enlace?

En romhacks no está.

Un Saludo.

Ese hack está incompleto, guy es ignorado por los enemigos, y abusa de sprites pequeños impidiendo poder dibujar mas personajes.

Fué abandonado hace ya tiempo.

Señor Ventura escribió:Ese hack está incompleto, guy es ignorado por los enemigos, y abusa de sprites pequeños impidiendo poder dibujar mas personajes.

Fué abandonado hace ya tiempo.

De de todas formas tengo la rom con los tres hacks aplicados: color, 2p y censura. Es una lastima que no se pueda jugar a 2p con la IA bien.

Señor Ventura escribió:Ese hack está incompleto, guy es ignorado por los enemigos, y abusa de sprites pequeños impidiendo poder dibujar mas personajes.

Fué abandonado hace ya tiempo.

Vaya decepción.

No era "arcade edition o algo así"?.
Clato,no modificaron la IA,para dos jugadores.
Pero,el objetivo,no era poner eso en pantalla?

El objetivo es ver un resultado que a uno mismo le valga.

Vi en el Twitter del Master Linkuei, que está ayudando a Mauro con los gráficos de FF, que todo el juego está siendo desarrollado en lenguaje C.

Imagínese este juego desarrollado en puro assembly, absorbiendo cada gota del sentir del Motorola 68K.

gynion escribió:El objetivo es ver un resultado que a uno mismo le valga.

Buena respuesta.
Suelo jugar a un player,en este caso.

@mcfly
¿Y por qué mencionas ese hack de 2 players, entonces? ¿te pensabas que era mejor o algo así?

Me he limitado a mencionar las características del hack,ya que han preguntado sobre ello.
Alguien dijo susceptible???

@mcfly
Perdona que te responda con preguntas, pero... ¿susceptibilidad a qué?

Alguien dijo curiosidad, más bien.

@gynion lllega un momento que me pierdo y no entiendo de que estamos hablando.
Mejor volver al tema del hilo.

naxeras escribió:

Señor Ventura escribió:Ese hack está incompleto, guy es ignorado por los enemigos, y abusa de sprites pequeños impidiendo poder dibujar mas personajes.

Fué abandonado hace ya tiempo.

Vaya decepción.

Bueno, digo guy porque es lo que se ve en el vídeo, pero me refiero al segundo jugador, claro.

Lo de los sprites... nota como a dos jugadores, al comenzar la partida, a cody le desaparecen los pies cuando sale el mapa. El juego usa originalmente una configuración de sprites de 8x8 y 16x16, y sobreutiliza precisamente los mas pequeños, por eso es mas difícil dibujar mas.

En el hack del final fight 2, siempre y cuando lleves a maki o carlos, puedes ver 6 personajes en pantalla con flickeos ocasionales, pero aceptables, precisamente porque usa otra configuración de sprites con respecto al primer final fight (aunque igualmente los desaprovecha, hay muchos parpadeos que no tendrían por qué producirse. Con haggar son mas persistentes por culpa de su brazo).

@mcfly
Creo que has hecho un gran aporte mencionándolo, y no es broma. Ese ejemplo, pone en valor el trabajo que se está haciendo y lo que se está logrando con el Mega Final Fight, que no debe de ser nada sencillo.

Dark_Schneider escribió:

VempireX escribió:

Dark_Schneider escribió:@Anibalfire el de Mega CD se mea holgadamente en el de Snes. FIN.

Sobretodo en jugabilidad verdad?!?! Permítidme que me descojone de vosotros dos, se nota que no habéis jugado a ninguna de las versiones, jugar más y bocachanclear menos es lo que debeis hacer, por qué tenga mas "extras" no quiere decir que sea mejor, por esa regla de 3, el Drácula X de Saturn, seria mejor que el de PS, y no lo es.

@Melkor^

Aceptamos pulpo como animal de compañía...pero no veo a tanta gente faltando y contradiciendo a @PepAlacant cuando habla del "ladrillo" por todo EOL.
O todos moros o todos cristianos.

Menuda guantá en la cara tienes, con la mano abierta.

@Alejo I
Tenéis 24 HRS de expulsar a este tío de Eol, queda avisada la moderación.

VempireX escribió:

Dark_Schneider escribió:

VempireX escribió:Sobretodo en jugabilidad verdad?!?! Permítidme que me descojone de vosotros dos, se nota que no habéis jugado a ninguna de las versiones, jugar más y bocachanclear menos es lo que debeis hacer, por qué tenga mas "extras" no quiere decir que sea mejor, por esa regla de 3, el Drácula X de Saturn, seria mejor que el de PS, y no lo es.

@Melkor^

Aceptamos pulpo como animal de compañía...pero no veo a tanta gente faltando y contradiciendo a @PepAlacant cuando habla del "ladrillo" por todo EOL.
O todos moros o todos cristianos.

Menuda guantá en la cara tienes, con la mano abierta.

@Alejo I
Tenéis 24 HRS de expulsar a este tío de Eol, queda avisada la moderación.

Fue expulsado una semana por ese comentario cuando lo publicó hace ocho o nueve días.

Si tienes algún otro problema, te sugiero que te pases por Feedback.

@Alejo I
Lo se, tengo todas las capturas, le baneais el mismo tiempo que a mí, solo que yo no amenacé a nadie físicamente, si ponéis a la misma altura de gravedad a ambos, dimelo en el siguiente mensaje, ya que me dejareis bien claro que en este foro se permiten las amenzas fisicas y asi tramitare antes todo el asunto.

@VempireX Yo aún no sé por qué me banearon la última vez. Me enteré porque me avisaron por privado un par de usuarios, apoyándome y diciéndome que tampoco lo entendían. Es mejor pasar.

Queda avisada la moderación....24 horas....jajajjajjajja....unas cervezas con éste debe ser una risa

En 24 horas muero

Un saludo a todos con los que he tenido la dicha de intercambiar mensajes.

Por favor, pasemos página.

@Alejo I Dalo por hecho de mi parte, solo he venido porque me he encontrado quoteado

Toda la última página tiene poco nada que ver que el hilo.

Alguien me actualiza si hubo novedades impresionantes? Me quedé en el tema de que se le había pedido permiso a Capcom.

@puch666 Hoy día es complicado prescindir del C, date cuenta que es lo que ha vuelto accesible el desarrollo a mucha gente. Como comentaba un compañero en este mismo foro, esos juegos en los 80-90 eran desarrollados por equipos profesionales compuestos de varios perfiles y dedicando su jornada laboral completa a darle forma.

Hoy día son proyectos a tiempo parcial y hechos como hobby en ratos libres. Si no fuera por las herramientas actuales sería inviable, y aún así siguen jugando en franca desventaja respecto a un equipo profesional.

@Vampirex si tienes algún problema con la moderación del foro, a feedback, deja de molestar a los mods de clásicas

dr apocalipsis escribió:

naxeras escribió:

Señor Ventura escribió:No guardas las animaciones completas en la vram, sino solo el gráfico del frame a mostrar durante el frame actual.

¿Como? ¿Estas seguro? ¿recargas la VRAM en cada frame? pensé que tenian que estar en las tablas todas las animaciones, saque esa conclusión al ver un video del hack de G&G de mega que dice que para poder meter todos los fames de animacion del demonio rojo tuvo que partir en más tiles el demonio para asi meter todas las animaciones en la VRAM.

https://youtu.be/Gp2Q2Blj15w?si=v0kByPhmUpEyWJGM&t=386

¿No hay limite de animaciones entonces en las maquinas de 16bits?

No, eso es una burrada.

Tienes un límite muy estricto en lo que puedes copiar a la VRAM entre el final de la última línea que se dibuja de la imagen anterior y el inicio de la primera de la siguiente.

En VRAM debes tener lo que vayas a dibujar en cada imagen, que es todo lo que se va a ver en pantalla.
A partir de ahí, y tras la carga inicial del nivel, puedes cambiar sólo un puñado de tiles de imagen a imagen, y ahí está el límite de las máquinas para poner muñecos grandes, no en moverlos por la pantalla. Por eso el Final Fight de Snes tiene esos marcazos, CAPCOM los usa para rascar tiempo para cargar los nuevos tiles de la siguiente imagen, que son sólo los que cambian por las animaciones de los personajes, nada más. Todo lo demás permanece en la VRAM, no se borra.

En los juegos VS, como el Street Fighter, todo el sprite de cada luchador cambia entre imagen e imagen, por eso la Snes va al límite cuando se podría pensar que 2 personajes no son tantos como los 4 o 5 de un beat em' up como el Final Fight. Pero, si te fijas, los muñecos de un beat 'em up están muchísimo menos animados y tienden a estar clonados.

En juegos con sprites más pequeños y frenéticos, como un Gunstar Heroes, mantienes en VRAM todas las animaciones posibles para mantener el rendimiento, pues no tienes la capacidad de mover toda esa cantidad de información entre imagen e imagen ni de blas. En este caso, todas las animaciones de los enemigos clónicos están en todo momento en memoria.

Hay que tener mucho cuidado sobre que información aceptas como buena en general, y más concretamente por estos lares.

Me interesa mucho esto, ahora entiendo lo comenta el creado del hack de ghost and ghouls y por eso tuvo que hacer los tiles mas pequeños porque si no, no le entraba todas las animaciones, es porque en vez de actualizar toda el sprite, actualiza el pequeñito que cambia en la animacion y es menos transferencia a la VRAM.

Mi preguta ahora es, ¿Cual es el limite? o sea Megadrive tiene 64kb de memoria y como bien has dicho no puede actualizar toda entre frame y frame, ¿El limite es el famoso DMA? ¿depende de la velocidad de acceso a memoria para sutituir los tiles?

Pero si es así entonces ¿da lo mismo animar un fondo que un sprite?, entiendo que no se calcula el limite para cada consola porque se usa para mas cosas ¿verdad?

Y es más tambien entiendo porque en SNES "se desperdician" los sprites haciendolos demasiados pequeños, no es porque eran unos vagos sino porque no da tiempo a actualizarlos si los haces más grandes que es lo que suponia yo.

Un Saludo.

naxeras escribió:Me interesa mucho esto, ahora entiendo lo comenta el creado del hack de ghost and ghouls y por eso tuvo que hacer los tiles mas pequeños porque si no, no le entraba todas las animaciones, es porque en vez de actualizar toda el sprite, actualiza el pequeñito que cambia en la animacion y es menos transferencia a la VRAM.

Mi preguta ahora es, ¿Cual es el limite? o sea Megadrive tiene 64kb de memoria y como bien has dicho no puede actualizar toda entre frame y frame, ¿El limite es el famoso DMA? ¿depende de la velocidad de acceso a memoria para sutituir los tiles?

Pero si es así entonces ¿da lo mismo animar un fondo que un sprite?, entiendo que no se calcula el limite para cada consola porque se usa para mas cosas ¿verdad?

Y es más tambien entiendo porque en SNES "se desperdician" los sprites haciendolos demasiados pequeños, no es porque eran unos vagos sino porque no da tiempo a actualizarlos si los haces más grandes que es lo que suponia yo.

Un Saludo.

Todo es relativo.

Megadrive tiene mas ancho de banda que snes, y además puede emplearlo también durante la pantalla activa. Un tile puede ser para sprites, o para fondos, y megadrive puede transferir mas.

Además el tiempo entre CPU y DMA se reparte, cuando uno funciona, el otro para, y como la cpu de la megadrive es mas potente, deja mas tiempo libre de DMA para transferir. Si por un lado puede transferir mas en el mismo espacio de tiempo, y por otro lado encima puede disponer potencialmente de mas tiempo para transferir, pues si, evidentemente hay una diferencia notable.


Sin embargo, snes es un sistema planar, los tiles no cuestan igual para sprites que para fondos, y también puede hacer cosas que ahorran ancho de banda, mientras que en el caso de megadrive implica un coste considerable.

La mejor respuesta que te pueden dar, es que depende del diseño del juego, una transfiere mas que la otra, o es mas eficiente que la otra.


La demo del bad apple puede funcionar en snes a 512x448 por ese tipo de razones, mientras que en megadrive a 320x224 además le tienen que poner unas bandas negras considerables. Eso no debería tener que estar pasando según las cifras, pero es que... todo es relativo.

naxeras escribió:

dr apocalipsis escribió:
No, eso es una burrada.

Tienes un límite muy estricto en lo que puedes copiar a la VRAM entre el final de la última línea que se dibuja de la imagen anterior y el inicio de la primera de la siguiente.

En VRAM debes tener lo que vayas a dibujar en cada imagen, que es todo lo que se va a ver en pantalla.
A partir de ahí, y tras la carga inicial del nivel, puedes cambiar sólo un puñado de tiles de imagen a imagen, y ahí está el límite de las máquinas para poner muñecos grandes, no en moverlos por la pantalla. Por eso el Final Fight de Snes tiene esos marcazos, CAPCOM los usa para rascar tiempo para cargar los nuevos tiles de la siguiente imagen, que son sólo los que cambian por las animaciones de los personajes, nada más. Todo lo demás permanece en la VRAM, no se borra.

En los juegos VS, como el Street Fighter, todo el sprite de cada luchador cambia entre imagen e imagen, por eso la Snes va al límite cuando se podría pensar que 2 personajes no son tantos como los 4 o 5 de un beat em' up como el Final Fight. Pero, si te fijas, los muñecos de un beat 'em up están muchísimo menos animados y tienden a estar clonados.

En juegos con sprites más pequeños y frenéticos, como un Gunstar Heroes, mantienes en VRAM todas las animaciones posibles para mantener el rendimiento, pues no tienes la capacidad de mover toda esa cantidad de información entre imagen e imagen ni de blas. En este caso, todas las animaciones de los enemigos clónicos están en todo momento en memoria.

Hay que tener mucho cuidado sobre que información aceptas como buena en general, y más concretamente por estos lares.

Me interesa mucho esto, ahora entiendo lo comenta el creado del hack de ghost and ghouls y por eso tuvo que hacer los tiles mas pequeños porque si no, no le entraba todas las animaciones, es porque en vez de actualizar toda el sprite, actualiza el pequeñito que cambia en la animacion y es menos transferencia a la VRAM.

Mi preguta ahora es, ¿Cual es el limite? o sea Megadrive tiene 64kb de memoria y como bien has dicho no puede actualizar toda entre frame y frame, ¿El limite es el famoso DMA? ¿depende de la velocidad de acceso a memoria para sutituir los tiles?

Pero si es así entonces ¿da lo mismo animar un fondo que un sprite?, entiendo que no se calcula el limite para cada consola porque se usa para mas cosas ¿verdad?

Y es más tambien entiendo porque en SNES "se desperdician" los sprites haciendolos demasiados pequeños, no es porque eran unos vagos sino porque no da tiempo a actualizarlos si los haces más grandes que es lo que suponia yo.

Un Saludo.

Lo primero es entender el coste de cada tipo de transferencia, tanto en ancho de banda como en ciclos de CPU.

Megadrive tiene varias ventajas muy grandes, que superan con mucho a la consabida mayor velocidad y ancho de banda del M68K, que es el mayor ancho de banda efectivo de la memoria tanto de vídeo como, sobre todo, de sistema, el DMA del propio VDP que permite copias autónomas entre VRAM y RAM/ROM, su capacidad para transferir datos también durante la pantalla activa y el formato de empaquetado de píxeles, que es más eficiente que el formato planar de la SNES.

A partir de ahí, se pueden hablar de cifras máximas teóricas si todos los recursos se enfocasen en la transferencia de datos, cosa que es irreal pues estás robando tiempo de ejecución a la CPU. Tanto como cuando haces DMA y congelas el bus principal, y por tanto al M68K aunque no al Z80, como cuando usas al mismo 68K para copiar datos, pues son ciclos que pierdes de procesamiento.

Suma la mayor eficiencia que te da el poder usar todos los tamaños de sprite al mismo tiempo a la hora de poder organizar los tiles que vas a transferir y minimizar así la necesidad de transferencias.

He leído por ahí una inmensa chorrada sobre como los juegos de Snes estarían poco optimizados por utilizar muchos sprites pequeños cuando la realidad es que el hardware no permite otra opción. Intenta refrescar sprites más grandes y dejas seco el bus antes de llegar al tercer muñeco. Por no hablar de la fantasía sobre dejar de dibujar sprites solapados en un sistema que no tiene buffer de profundidad ni el hardware para hacerlo. Intentar hacerlo por software, y hacerle el bypass al propio hardware de sprites, para hacer algo como un sprite culling sería infinitamente más ineficiente que usar el hardware que ya hay para mover sprites. Eso se hace en máquinas infinitamente más capaces pero sin hardware dedicado para esa función. Un completo disparate.

Es muy fácil ver esto con los hacks de los Final Fights para aumentar personajes en pantalla. Estos juegan con el overhead natural que deja Capcom para no sufrir (grandes) ralentizaciones en el juego comercial. Al enchufarle un personaje adicional, el sistema colapsa rápidamente en cuando son necesarias más transferencias de las que puede satisfacer el sistema. Es muy fácil decir que el sistema puede con otro personaje cuando coincide que no hay los suficientes refrescos de tiles que copen el ancho de banda, pero sólo hay que ver más de 5 segundos de gameplay normal para ver a los hacks arrastrarse en rendimiento y glitchear como salvajes al superar tanto el número de sprites por línea como hasta el de tiles únicos por pantalla que permite Snes.

Megadrive palma antes por el límite de sprites por línea.

Y lo de que el vídeo de Bad Apple vaya mejor en SNES que en Megadrive es ya directamente mentira:

Megadrive Stock: 320x224@30FPS 2BPP simulados bajo 4BPP reales:

Snes Stock: 256x192@20FPS 2BPP nativos:


Es AGOTADORA la actitud de algunos personajes en este subforo e incomprensible la barra libre que tienen.

dr apocalipsis escribió:
Es AGOTADORA la actitud de algunos personajes en este subforo e incomprensible la barra libre que tienen.

Por favor, este hilo ya es lo bastante complicado. Si alguien tiene alguna queja, que use la opción de reporte.