Curiosidades de Mega Drive (no 56K)

@BMBx64 en las 16 bits, ¿Cómo te aseguras de que un juego va a 60 fps, con qué emulador? En este caso MD.

¿Y en SNES?

Porque los hz entiendo que es sencillo: 60 progresivo, 30 entrelazado.

Hay que rescatar un listado que ruló durante un tiempo en SEGA-16, en donde se explicaba y se mostraba que a la SNES le costaba llegar a 60 fps incluso por detrás de la Pc-Engine y NES en ese aspecto.

P.D: Buen post

Vivan los 30fps.

Y las bandas negras.

Metal slug ftw.

Me alegro que haya gustado el texto , yo en la fase de la vagoneta lo poco que hacía era pulsar hacia atrás, así me daba más tiempo de reaccionar

@Sexy MotherFucker
Contando ticks en Fusion, busco el movimiento continuo de un objeto (a poder ser sin física) y de la cámara de scroll para ver si cambian en 1 o 2 tiempos.

En este caso primero descubrí que iba a 30, aunque como dice robotnik en su día ya noté que iba más pausado, luego busqué info y di con el game genie para 60

Sexy MotherFucker escribió:@BMBx64 en las 16 bits, ¿Cómo te aseguras de que un juego va a 60 fps, con qué emulador? En este caso MD.

¿Y en SNES?

Con el bsnes te sale en la parte inferior de la ventana del emulador los fps a los que corre, aunque se refiere a los fps a los que corre el emulador, no el juego en sí. Y es que calcular los FPS a los que corre un juego de 16 bits es bastante difícil, ya que depende de en qué elemento te fijes. En los juegos que he desensamblado, hay una cola de transferencias DMA con los nuevos gráficos para el siguiente frame; si la cola es muy larga y no da tiempo a enviarse en un VBlank, lo que no se haya enviado se va al siguiente frame, así que algunos sprites se habrán actualizado en cada Vlbank (60fps) y otros solo en algunos VBLank (menos de 60fps).

Sexy MotherFucker escribió:Porque los hz entiendo que es sencillo: 60 progresivo, 30 entrelazado.

Al revés, hombre... Los 60 cuadros por segundo son 60 CAMPOS, es decir, modo entrelazado. Los 30 sí son frames completos (formados por el campo inferior y el campo superior), por tanto es modo progresivo.,

@Sexy MotherFucker @BMBx64 Para saber los fps de un juego lo mejor es coger el Regen y poner el juego a 1fps. Si cambia cada frame es que va a 50/60fps, si cambia cada 2 va a 25/30fps, etc.

@BMBx64 @magno gracias a ambos. Me ha parecido siempre un asunto muy interesante sobre el que hay poquísima información fiable en internet, y del que me gustaría ponerme a arrojar luz algún día aportando mi pequeño grano de arena al respecto.

Y sí, lo de los hz lo dije al revés, se me fué la flapa pero eso sí lo sabía.

Manveru Ainu escribió:@Sexy MotherFucker @BMBx64 Para saber los fps de un juego lo mejor es coger el Regen y poner el juego a 1fps. Si cambia cada frame es que va a 50/60fps, si cambia cada 2 va a 25/30fps, etc.

¿Así de práctico y rápido? ¿Es un método 100% fiable?

Señor Ventura escribió:Vivan los 30fps.

Y las bandas negras.

Metal slug ftw.

No se trata de eso capullín, sino de averiguar hasta qué punto los 20 o 30 fps son producto de la incapacidad técnica de estas máquinas para ejecutarlos queriendo conseguirlos, o bien son premeditadamente buscados por motivos de diseño y/o rendimiento en campos concretos.

Y por supuesto para utilizar los datos como arma arrojadiza en LA GUERRA

@Sexy MotherFucker

Si se trata de eso. Yo digo que vivan los 30fps, y así nunca lo sabremos

Editado: Aclaro, 30fps no tiene por qué ser 30hz.

@Sexy MotherFucker Claro. Es como grabar una partida a 50/60fps y luego reproducirla frame a frame a ver si la imagen cambia cada frame o cada 2. No tiene ningún misterio jeje. Puedes buscar partidas en youtube a 50/60fps, pausar el vídeo y darle a la tecla punto para avanzar frame a frame, es lo mismo.

@Manveru Ainu
Yo lo que hago es pausar la emulación y luego avanzar frame a frame, pulsando manualmente un botón, lo cual me permite controlar todos los tiempos de todo lo que pasa en pantalla y lo puedo ir anotando, si Fusion está seteado NTSC entiende el segundo como 60ticks.

Me fijo en los elementos por separado, si pillas a un personaje saltando en una parábola te vas a llevar unos resultados erróneos por la deceleración del movimiento, por eso busco movimientos continuos, además de diferenciar entre movimiento de coordenadas y refresco de animación.

Para el scroll lo mismo, muchas veces la cámara tiene desplazamiento suave y empieza con un semáforo o temporizador, hasta que ya puede colocar 1 pixel o más de desplazamiento.

Una demo técnica con contador de fps:

@BMBx64 Ten en cuenta que todo el juego está a un mismo framerate. No necesitas fijarte en algo en concreto sino sólo en ver si algo en pantalla se mueve.

Para eso por ejemplo el Exodus es muy útil porque puedes marcar con recuadros los scrolls y los sprites, y si algo se mueve lo ves rápido. La propia mega drive permite dibujar un marco alrededor de los sprites, pero ningún emulador tiene eso implementado. Luego Blast'em está muy abierto a las sugerencias de la gente y trae muchas opciones para cositas así, aunque aún no me he metido mucho en ese emulador.

Yo normalmente en mis demos de estrés siempre meto el debugueo de los fps, aunque tenga que modificar el código para ello ya que la mega drive no tiene un reloj interno. Es últi para ver si se rebasan los tiempos disponibles para el main y para el Vblanking

@Manveru Ainu
Claro, cuando miro los ticks es para saber las tasas de actualización en general, además del framerate.

Yo también meto siempre contador de fps en todo lo que hago

@Señor Ventura en un juego de conducción o de peleas los 60 fps deben estar los primeros en la lista de prioridades. Y en un shooter en el 99% de los casos también. Que Metal Slug sea un juego de avance lento porque el principal atractivo de la experiencia sea observar el recargado entorno artístico y animaciones mientras lo vas destruyendo, y por ello haya que renunciar a algo de fluidez, no implica que ese sea el camimo a seguir, refiriéndome siempre a dichos géneros.

A mí me interesa saber hasta donde son capaces de llegar estas máquinas en dicho contexto, y cúal es la más capaz de todas cargando una escena de similar calibre.

BTW sea me ocurre que a 20 fps y con una rom generosa la SNES podría haber dado unos RPGs aun más preciosistas recargados de detalle y animación.

Es que hay géneros que necesitan precisión, y para eso el juego tiene que moverse fluido (además de ser una gozada visual per se).

Sexy MotherFucker escribió:A mí me interesa saber hasta donde son capaces de llegar estas máquinas en dicho contexto, y cúal es la más capaz de todas cargando una escena de similar corte.

Megadrive. Menudo misterio xD

Mas cpu, mas dma, una tabla de atributos para sprites que no se descuelga...


Lo que ocurre es que en el lado contrario tenemos a la snes aún con algunos misterios que pueden dar mucho juego, y eso es muy distintivo.

Y algunas ventajas que otorgan su eficiencia que pueden proporcionar darle la vuelta a la tortilla del rendimiento, no lo olvidemos.

Sexy MotherFucker escribió:BTW sea me ocurre que a 20 fps y con una rom generosa la SNES podría haber dado unos RPGs aun más preciosistas recargados de detalle y animación.

Puedes acumular tiles cada 3 tics, y funcionar a 60fps, también.

Pero mayormente no te merece la pena si no es para hacer un gran trabajo con escenarios con mucho movimiento.

¿Y por qué esta fiebre de los FPS ahora también en las consolas retro?
No veo la necesidad de que un plataformas, un Probotector, Metal Slug o Street Figher 2 tenga que ir a 60 fps. El que un personaje no se actualice cada frame no quiere decir que la consola no pueda actualizarlo cada frame, sino que si tienes que poner unas tiles diferentes en cada frame, todo eso ocupa sitio en ROM (muy preciado en aquella época) y tienes la necesidad de hacer un extra de diseño gráfico para cada postura de personaje.
En un Virtua Racing o en el Starwing sí que veo esa necesidad de cuantos más FPS mejor, pero no overclockeando el chip, sino habíendolo diseñado desde el principio a más tasa de frames.

¿porque no hay un hilo de curiosidades de Super Nintendo? ya que en el de Mega casi se habla mas de SNES que de la consola del que trata.

Crissaegrim escribió:¿porque no hay un hilo de curiosidades de Super Nintendo? ya que en el de Mega casi se habla mas de SNES que de la consola del que trata.

Por pereza.

@magno el tema de los gráficos y los fps se habla mucho en consolas actuales, y si hay algo claro es que los gráficos no son tan importantes, pero en juegos de acción los fps afectan de manera definitiva a la jugabilidad, por lo que es importante como lo que más.


Volviendo a las curiosidades, os dejo otro vídeo del crack GameHut, donde explica cómo está hecho el suelo 3D del Mickey Mania: Mickey Mania's "Impossible" 3D Chase - How Was It Done?. Resumiendo y para los que le cueste el inglés, el efecto se hace cambiando los colores de cada píxel de cada línea horizontal. Con este truco, algo que parece imposible se convierte en algo trivial gracias al ingenio del personal.

Siempre pongo como ejemplo de emulación de movimiento con animacion de colores esta gran web con muchos ejemplos de este truco muy usado en aquella época: http://www.effectgames.com/demos/canvascycle/. Si le dais al botón "show options", veréis cómo se animan los colores. Si ponéis alguna escena con lluvia (el quinto en la lista por ejemplo), el efecto es brutal.

Crissaegrim escribió:¿porque no hay un hilo de curiosidades de Super Nintendo? ya que en el de Mega casi se habla mas de SNES que de la consola del que trata.

Porque hay más de un pesao que no deja de postear cosas "del otro lado" para dar por
Yo agradecería que abriesen un hilo, en lugar de ensuciar éste. Se hace cansino.

Manveru Ainu escribió:@magno el tema de los gráficos y los fps se habla mucho en consolas actuales, y si hay algo claro es que los gráficos no son tan importantes, pero en juegos de acción los fps afectan de manera definitiva a la jugabilidad, por lo que es importante como lo que más.


Volviendo a las curiosidades, os dejo otro vídeo del crack GameHut, donde explica cómo está hecho el suelo 3D del Mickey Mania: Mickey Mania's "Impossible" 3D Chase - How Was It Done?. Resumiendo y para los que le cueste el inglés, el efecto se hace cambiando los colores de cada píxel de cada línea horizontal. Con este truco, algo que parece imposible se convierte en algo trivial gracias al ingenio del personal.

Siempre pongo como ejemplo de emulación de movimiento con animacion de colores esta gran web con muchos ejemplos de este truco muy usado en aquella época: http://www.effectgames.com/demos/canvascycle/. Si le dais al botón "show options", veréis cómo se animan los colores. Si ponéis alguna escena con lluvia (el quinto en la lista por ejemplo), el efecto es brutal.

A coste CERO de cpu.

danibus escribió:

Crissaegrim escribió:¿porque no hay un hilo de curiosidades de Super Nintendo? ya que en el de Mega casi se habla mas de SNES que de la consola del que trata.

Porque hay más de un pesao que no deja de postear cosas "del otro lado" para dar por
Yo agradecería que abriesen un hilo, en lugar de ensuciar éste. Se hace cansino.

Mas pesado se hace leer desprecios.

Si te interesan los detalles técnicos, te interesan los detalles técnicos.

Manveru Ainu escribió:@magno el tema de los gráficos y los fps se habla mucho en consolas actuales, y si hay algo claro es que los gráficos no son tan importantes, pero en juegos de acción los fps afectan de manera definitiva a la jugabilidad, por lo que es importante como lo que más.

Esto es subjetivo a mi entender: que en un salto de un personaje en el Street Fighter 2 que dure por ejemplo 20 frames, me da igual que el personaje se haya actualizado 1 vez por frame en 20 posturas diferentes (60 fps) o que lo haga cada 2 frames dibujando 10 posturas diferentes (30fps). A 60 fps queda más artístico y más fluido, sí, pero a la jugabilidad, en mi caso, no afecta.

La cuestión es que a 30fps todo se para durante 1 frame, y luego se desplaza 2 para no ralentizar la acción, ¿no?.





En este link se explica detalladamente, luego le echo un vistazo mas a fondo:
http://www.vandal.net/foro/cgi-bin/foro ... eplica=186

Señor Ventura escribió:La cuestión es que a 30fps todo se para durante 1 frame, y luego se desplaza 2 para no ralentizar la acción, ¿no?.

En este link se explica detalladamente, luego le echo un vistazo mas a fondo:
http://www.vandal.net/foro/cgi-bin/foro ... eplica=186

Precisamente ahí comentan lo que dije antes: actualizar a 60 fps la posición de un personaje no es habitual, sino que se suele hacer cada 2 o 3 frames, manteniéndolo esa cantidad de frames en una postura concreta pero pudiéndolo avanzar si la velocidad del movimiento lo requiere (como en el ejemplo de Axel).

Lo verdaderamente importante en este tipo de juegos beat'em up o uno vs uno es que sea fluido aunque la animación no lo sea tanto: es decir, que siempre hagas un salto por ejemplo en 20 frames, y ya actualizas la postura del personaje en cada uno de esos 20 frames tanto como espacio en ROM tengas para guardar las animaciones.

No hay que olvidar que mientras más fps más precisión tienes y más ventaja sacas de tus habilidades.

Jugar "a cámara lenta" no es malo. Es una ayuda para los jugadores que no tienen tantos reflejos o habilidad, pero limita la experiencia de los jugadores más "expertos" digamos. Yo por ejemplo solía jugar al Smash TV a 5fps con un mando con autopausa, para tener alguna posibilidad porque a 50 o 60fps era una masacre xD

Detalles técnicos sobre la realización de Aladdin para Mega Drive:
https://gamehistory.org/aladdin-source-code/

que mitico el comiz zone, es mi juego favorito de megadrive

Diskover escribió:Detalles técnicos sobre la realización de Aladdin para Mega Drive:
https://gamehistory.org/aladdin-source-code/

Muy interesante, el pavo ha encontrado varios personajes y cosas que no aparecen en el juego final en la documentación/softw que ha encontrado, por lo visto se vieron en la demo del CES donde presentaron el juego, pero luego los quitaron (mas bien no los pusieron).

Por ejemplo, en el bonus aparece una manivela que se mueve (como en las tragaperras de antaño), en el juego final no sale:




Enemigos varios

https://youtu.be/3VuXtbZaZW0
https://youtu.be/_dPIBDLlKJo
https://youtu.be/G5LRtXflISs


Comenta algunos de los programas hechos para crear el juego, como el Editor de niveles


Aqui un posible reparto del uso de la memoria de la ROM (en aquella época, la memoria era cara):

2048K – Total Memory Available on Cartridge






Hay más cositas, está interesante

@danibus está todo muy bien pero ya podría haber publicado el código del juego...

Creo que ha dicho que lo releasaran pronto, a ver si cae la breva

Curiosidad express..

The character was made to look angrier, and his palette changed from purple to brown to reinforce the whole "Bear" thing. It didn't really work; people still think he's a cat.

UGHS!

La primera vez que jugué a la versión JAP de este juego vi al bicho lila que lanzaba mal las bolas y estas no me daban, pensé que era un fallo del emulador

El abrazo del oso amoroso

El bicho tiene gracia porque la cabeza sigue el estilo South Park, mirando siempre a la cámara, pero en cambio el cuerpo es coherente con la acción.

Que gran juego el Dinamite...ese seguro que tiene un montón de curiosidades por analizar

Curiosos los múltiples cambios y diferencias que hay entre las versiones NTSC(japo)-PAL del juego de Treasure.

Es uno de mis favoritos de la consola.
Pocos amigos de la época lograron pasárselo.

Otro que también cambia bastante de sprites entre una región y otra es Ristar.

Dos obras maestras de las plataformas noventeras.

Paprium escribió:Curiosos los múltiples cambios y diferencias que hay entre las versiones NTSC(japo)-PAL del juego de Treasure.

Es uno de mis favoritos de la consola.
Pocos amigos de la época lograron pasárselo.

Otro que también cambia bastante de sprites entre una región y otra es Ristar.

Dos obras maestras de las plataformas noventeras.

Varios de los cambios eran por cuestiones comerciales, se creia (al igual que con Nintendo) que los personajes ``monosos´´ no tenian tanto tiron comercial, por eso retocaban los sprites para hacerlos mas duros.

Ristar tiene alguna alteración mas drástica, como el jefe del hielo por que el tema del ``gato´´ que se escalda del original nipon hace referencia a una frase popular japonesa. Como aquí nadie lo entendería...pues se cambio a un monstruo de hielo random.

El canal GameHut ha subido un trailer que contiene un breve resumen sobre los cambios que ha hecho para su Sonic 3D Director's Cut. No sé si todavía esconderá alguna novedad más, de momento la cosa queda así, que no está nada mal:

https://www.youtube.com/watch?v=TO-N2WHbnqU

Todo lo que enseñan en Gamehut es genial

Del Dynamite Headdy siempre pensé que el jefe secreto que lanza dinero era una referencia a algún directivo de Konami
https://www.youtube.com/watch?v=Ve3u1__6mXQ

Hace poco salió información sobre ventas y algunos acuerdos entre Treasure y Sega (sacado de vandal):

Another interesting point was Maegawa discussing Treasure's initial contract with Sega. He said Sega paid them the equivalent of $500,000 plus $2-3 per game sold.
Maegawa also said that Gunstar Heroes and Dynamite Headdy were probably the only Treasure games that Sega made a profit from. All of the others were in the red.
While developing Puyo Puyo (which would become a massive hit in Japan), Compile ran out of funds and was going to collapse, but Sega bailed them out and got the rights to publish Puyo Puyo. It became a huge hit in the arcade and subsequently on the MD. Following that, Nintendo approached Niitani and wanted him to sign a contract to exclusively publish Puyo Puyo on the Super Famicon, apparently completely unaware that the game was already on the MD.

--

Dejo ésta reinterpretación del Castlevania Bloodlines, según va avanzando el vídeo va explicando como la música no le sacaba todo el partido a Mega Drive pues parece que usa un esquema de 5 canales similar a NES y como la ha ido mejorando.
https://www.youtube.com/watch?v=PyvIUwGD7AY

Como siempre, ¡magníficos aportes!

Ay cómo disfrutaría de un cacho hack del Bloodlines que mejorara aún más la excelente música que tiene.... (De mis castlevania favoritos sin duda)

BMBx64 escribió:Del Dynamite Headdy siempre pensé que el jefe secreto que lanza dinero era una referencia a algún directivo de Konami

Pues por poco pero no,se dice que tiene el careto de Hayao Nakayama, el presidente de Sega entonces nada menos xddd. Una puyita amistosa.

BMBx64 escribió:Todo lo que enseñan en Gamehut es genial

Del Dynamite Headdy siempre pensé que el jefe secreto que lanza dinero era una referencia a algún directivo de Konami
https://www.youtube.com/watch?v=Ve3u1__6mXQ

Hace poco salió información sobre ventas y algunos acuerdos entre Treasure y Sega (sacado de vandal):

Another interesting point was Maegawa discussing Treasure's initial contract with Sega. He said Sega paid them the equivalent of $500,000 plus $2-3 per game sold.
Maegawa also said that Gunstar Heroes and Dynamite Headdy were probably the only Treasure games that Sega made a profit from. All of the others were in the red.
While developing Puyo Puyo (which would become a massive hit in Japan), Compile ran out of funds and was going to collapse, but Sega bailed them out and got the rights to publish Puyo Puyo. It became a huge hit in the arcade and subsequently on the MD. Following that, Nintendo approached Niitani and wanted him to sign a contract to exclusively publish Puyo Puyo on the Super Famicon, apparently completely unaware that the game was already on the MD.

--

Dejo ésta reinterpretación del Castlevania Bloodlines, según va avanzando el vídeo va explicando como la música no le sacaba todo el partido a Mega Drive pues parece que usa un esquema de 5 canales similar a NES y como la ha ido mejorando.
https://www.youtube.com/watch?v=PyvIUwGD7AY

La música del Castlevania Bloodlines es un caso un poco raro para un juego tan tardío, como el del SSF2: No usan samples en absoluto e incluso diría que tampoco echan mano del PSG, es 100% FM. Normalmente los juegos usan el canal de los samples para la percusión y el PSG para cierto tipo de instrumentos.

Os dejo un vídeo donde Gamehut explica a petición de sus seguidores el sencillo aunque efectivo efecto de rotación de la torre del Mickey Mania Mickey Mania's 3D Rotating Tower - How Was It Possible?

@Manveru Ainu @BMBx64

Si en NTSC el ancho de banda nominal del DMA de la Megadrive a 320x224 y 60 fps es de 7,22 kb por frame; ¿A cúanto asciende exactamente en consolas PAL?

Sexy MotherFucker escribió:@Manveru Ainu @BMBx64

Si en NTSC el ancho de banda nominal del DMA de la Megadrive a 320x224 y 60 fps es de 7,22 kb por frame; ¿A cúanto asciende exactamente en consolas PAL?

No existe un valor exacto comprobado. Según la documentación "oficial", la Mega transmite por línea hasta 18 bytes con del display activo, y 205 bytes con el display desactivado.

Durante el periodo del VBlank (cuando no se dibuja la pantalla) a 60fps son 38 líneas, y a 50fps son 88, por lo que (siempre hablando del modo 320x224) tenemos unos 7500 bytes a 60fps, y 17500 bytes a 50fps.

Eso aparte de las 224 líneas del dibujo de pantalla, que actualizando la pantalla serían unos 4000 bytes, pero con el dibujo desactivado (para por ejemplo dibujar a fps/2) pues tendríamos otros 205*224 = 46000 bytes tanto en pal como en ntsc.

Si usamos un frame completo para dibujar: periodo de dibujo con display desactivado + todo el periodo del VBlank, en teoría podemos dibujar hasta unos 54k a 60fps, y 64k a 50fps.

Para usar modos 320x240, habría que pasar 16 líneas del VBlank al display activo y recalcular. En PAL (único modo donde se puede poner a 240), serían unos 3k menos en el VBlank

@Manveru Ainu gracias por la explicación; ¿Pero podrías darme un valor aproximado?

De 7,22 kb pasaríamos más o menos hasta... ¿¿¿???

17500 bytes a 50fps.

17,y pico Kb ¿?

@Sexy MotherFucker sí, eso es, unos 17-18kbytes, o el equivalente a unos 550 tiles.

@Manveru Ainu una puta burrada, muchas gracias

Flipo porque en comunidades como SEGA-16 no se tomen más en serio este potencial, o al menos yo no he visto hilos/post dedicados. De hecho cuando se estaba iniciando el proyecto del SF2 definitivo ni siquiera se planteaban desactivar unas pocas scanlines para ganar ancho de banda, tropezándose todo el rato con los 7,22 kb cuando querían meter un Zangief haciendo su doble patada, o a Thunderhawk.

Sexy MotherFucker escribió:@Manveru Ainu una puta burrada, muchas gracias

Flipo porque en comunidades como SEGA-16 no se tomen más en serio este potencial, o al menos yo no he visto hilos/post dedicados. De hecho cuando se estaba iniciando el proyecto del SF2 definitivo ni siquiera se planteaban desactivar unas pocas scanlines para ganar ancho de banda, tropezándose todo el rato con los 7,22 kb cuando querían meter un Zangief haciendo su doble patada, o a Thunderhawk.

Yo también descarté el Pal para un estrifa por lo que hablamos ayer. Cuando le di vueltas al port, lo mejor que se me ocurría es dejar caer esos slowdowns cuando salgan frames grandes de esos. Si para cargar un frame tocho necesita 2 frames de refresco, pues adelante. El efecto de que el juego baje a 58 o 59 fps es mínimo, mucho mejor que mantenerlo a 50fps. También se puede usar un buffer para ir adelantando el siguiente frame de un personaje. Reduciría bastante esos casos de slowdowns.

@Manveru Ainu o directamente se podrían desactivar 8 o 16 scanlines. Nos acercaríamos mucho al aspect-ratio del ARCADE, iríamos desahogados de ancho de banda, y tendríamos todas las animaciones en unos sprites hermosotes.

Total, al original llevamos toda la vida jugándolo así:



No veo ninguna deshonra un poco de black borders a cambio de ganar resolución horizontal, frames, y sprites más grandes.

Estáis hablando teóricamente de como se haría un SF2 cuasiperfecto para MD o existe algún proyecto en marcha para hacerlo y han tomado decisiones erroneas como las que comentáis?

@Calculinho existía hasta donde yo sé; se filtraron algunas propuestas de sprites, escenarios, etc, pero la gente no se bajaba del burro, ni se ponía de acuerdo, ya que la mayoría quería: 320x224, full screen, 60 fps, personajes más tochos, con + animaciones, Shadow & Highlight para aumentar la paleta de los fondos, XGM driver a tope (no el simple parche a 2 canales), etc. Y claro así se tropezaban cada 2x3 con el ancho de banda de 7,22 kb.

En cambio una consola PAL podría con todo eso, sólo que a 50 fps...

Sexy MotherFucker escribió:@Manveru Ainu o directamente se podrían desactivar 8 o 16 scanlines. Nos acercaríamos mucho al aspect-ratio del ARCADE, iríamos desahogados de ancho de banda, y tendríamos todas las animaciones en unos sprites hermosotes.

Total, al original llevamos toda la vida jugándolo así:



No veo ninguna deshonra un poco de black borders a cambio de ganar resolución horizontal, frames, y sprites más grandes.

La cosa es que la resolución original es 384x224. El 384 es inalcanzable, pero si además recortamos el 224... También es que la Mega podría con los sprites originales salvo quizás los de Zangief y tal vez Sagat y Dalshim. Sería menos impacto hacer lo que digo cuando esos personajes sobrepasen el límite que no tener que recortar todo cuando la mayoría de personajes no tienen problemas.

Un port en mega lo más 1:1 posible tiene como problema real de verdad el reducir los fondos a 2 y el gestionar los tiles de los fondos que, si no se quieren retocar, no caben en la VRAM y necesita de una app + motor que gestione eso. El resto no es tan difícil. Es un coñazo, como pasar un personaje completo al juego que me costó tela, pero no es difícil.