Cross Fever para XMvsSF, MSHvsSF y Marvel vs. Capcom arcade

MVC1 V3: P1 + P2 contra P3 + P4. P1 y P3 eligen el primer luchador; P2 y P4 eligen el segundo y el ayudante. Los seis ataques usan los mismos botones de RetroPad en cada puerto: Y/X/L = LP/MP/HP, B/A/R = LK/MK/HK. Cada compañero conserva su control independiente durante Duo. Cambiar el dueño del control, jugar con tres personas y añadir control compartido clásico siguen siendo peticiones separadas.

Una comprobación nueva de V2.2 reprodujo un error concreto en el perfil Modern: L enviaba PPP y R enviaba HP, en lugar de HP/HK. V3 mantiene la misma asignación de seis botones en Modern, Classic y 6Panel. Esto no identifica la causa de otro reporte de inicio que no especificó su paquete o core.

Consulta la instalación y los controles actuales: paquete, core cargado, recibo del juego y asignaciones de los cuatro puertos. Un reporte sin identificar paquete o core no demuestra un fallo de la versión actual. Las entradas simuladas no prueban cuatro mandos físicos ni una partida y revancha entre cuatro máquinas por internet.

Archivo V2.2: usa P1/P3 contra P2/P4; no mezcles su ROM o core con V3. Se conservan los paquetes de Windows x64, Mac Apple silicon · macOS 26+ y Linux x64, su guía, resultados y registro de archivos. V2.2 se probó con cuatro instancias de RetroArch 1.22.2 en una sola máquina Linux mediante un lobby y relay locales, no entre cuatro máquinas por internet.

Las descargas y la investigación históricas siguientes conservan sus versiones. No son resultados de V3. Las instrucciones de los instaladores .cmd de XMvsSF y MSHvsSF no sustituyen la guía de MVC1 V3.

Cuatro personas. Cuatro luchadores. Una sola placa arcade.

Marvel vs. Capcom de Dreamcast tenía Cross Fever: dos equipos de dos, cada luchador con su propio control y los cuatro en pantalla a la vez. La placa CPS-2 —la de los gabinetes, la de Fightcade— nunca lo tuvo. Ahora sí, en X-Men vs. Street Fighter, en Marvel Super Heroes vs. Street Fighter y en MVC1 arcade, a partir de tu propia ROM.

XMvsSF y MSHvsSF tampoco tenían el Duo de MVC1, así que también lo reciben, con el cielo de meteoros de MVC1 detrás: con QCB + HP + HK tu luchador hace su pose, tu compañero entra volando y peleas con los dos hasta que se acaba el tiempo.

Cinco formas de jugar

MSHvsSF tiene dos instaladores por modo: uno para la ROM USA 970827 (mshvsfu.zip) y otro para la Euro 970625 (mshvsf.zip), la que usa Fightcade. Los dos instalan la misma v5.

SHA-256 de los instaladores: XMvsSF Duo v3 4b20caf3284f13692c3d5f1009240cf45f09109df152861bebe5ce67793179ad, XMvsSF cuatro jugadores v2 4413b19dbac91415bd1469aba448e5cfe373cf4977d15940e3448aaee8f69c70, MSHvsSF Duo v5 ce4b8cbd7d41bd441057b249ce236f265a2c3e40e9e909b743b81e443a46bb13, MSHvsSF cuatro jugadores v5 18858b191291e1cf292ba41cad85e857a974042acd9939106ce038bfe3b5f6be, MSHvsSF Duo v5 Euro 6344b7800a03279a147f666f4465cad87dac305c8e1ee8ee18d4a773ac9047bc, MSHvsSF cuatro jugadores v5 Euro a111427640dea5ebfb83f82abd674276c4d740033ae4f18711b500d36f594d13, MVC1 v2.2 aba28617ac229591ab6a4bedfc6a4a35b8ebb2c7281ee898e29d205f9be4b4a4. Cada uno tiene además un paquete de pruebas con README, especificación del parche, verificación e instalador en Python: XMvsSF Duo v3, XMvsSF cuatro jugadores v2, MSHvsSF Duo v5, MSHvsSF cuatro jugadores v5, MSHvsSF Duo v5 Euro, MSHvsSF cuatro jugadores v5 Euro, MVC1 v2.1.

Controles de las versiones históricas

Como en el Duo propio de MVC1, el modo necesita dos niveles de medidor. No se gasta nada al empezar; el medidor se ve lleno mientras dura y, al terminar, cuesta dos barras completas (una tercera a medias se conserva). Empezar con nivel 3 da un modo más largo y vacía el medidor. Las barras TIME muestran la duración del modo, aparte del reloj del asalto. En XMvsSF y MSHvsSF de cuatro jugadores, P3/P4 necesitan el perfil que usa Start/Coin como MK/HK. El core MVC1 v2.2 traduce esas líneas internamente: asigna seis ataques normales y deja Start/Coin sin entrada del juego.

Esta edición en español resume la versión y sus resultados. La investigación completa en inglés conserva los listados, hashes y comparaciones técnicas de cada compilación.

MSHvsSF: los cuatro siguen peleando

Ryu y Ken se enfrentan a Spider-Man y Captain America. Los cuatro paneles muestran las entradas físicas y la palabra de control que recibe cada luchador. Botones distintos iluminados simultáneamente indican propietarios distintos dando órdenes.

En la grabación completa, los cuatro permanecen activos durante 997 callbacks muestreados. Con las mismas entradas, la versión anterior, que solo cambiaba la propiedad de los controles, mantenía a los cuatro juntos apenas 17 callbacks y no activaba un modo sostenido.

La versión posterior msh-combined-08 reúne los controles, la selección, el modo temporizado y el HUD. En una prueba acotada, las 264 muestras de entradas llegaron al propietario correcto, incluidas las 24 combinaciones de jugador y botón de ataque. Se observaron seis Hypers alternados de Ryu y Ken con el medidor almacenado en cero durante el modo.

MVC1: Variable Cross con cuatro propietarios

Zangief y Ryu pelean contra Spider-Man y Captain America. Se usan controles normales en un emulador local de diagnóstico, sin escrituras de estado de juego ni un estado guardado cargado al inicio.

Las dos barras TIME aparecen sobre los medidores de niveles; el fondo de meteoros es el propio de MVC1. No es una reconstrucción animada. El prototipo posterior de MVC1 ocupa 418 bytes y tiene pruebas adicionales de selección, controles, temporización y guardado/restauración. No atribuimos esas mejoras al video antiguo.

Un equipo no es un control

La pertenencia a un equipo sigue determinando rivales, proyectiles, medidor, relevos y colisiones. El nuevo propietario del control es independiente de esa pertenencia. Al cambiar de personaje activo, el compañero conserva a su propio jugador.

El MVC1 de arcade permite que los dos compañeros actúen durante Variable Cross, pero originalmente reciben controles compartidos. El relevo histórico utilizado en Kaillera asignaba el control al dueño del personaje activo. Cross Fever de Dreamcast permite propietarios independientes, incluidos ambos compañeros actuando juntos. Estas tres situaciones no son equivalentes.

El ejecutable de Dreamcast usa cuatro registros de controles y selecciona la entrada de cada luchador. Su código SH-4 se estudia para traducir el comportamiento a 68000; no se puede pegar directamente en el programa CPS-2. Los archivos Phoenix ayudan con el programa descifrado, no añaden puertos de control.

Cableado nativo de los prototipos

Los equipos son P1/P3 contra P2/P4. Cada persona tiene direcciones y seis botones. Los botones MK/HK reutilizan líneas de Start/Coin, por lo que este diseño requiere juego libre y un cableado propio.

Los registros son IN0 $804000, IN1 $804010 e IN2 $804020. Las líneas de servicio y EEPROM se conservan. Fuera del combate, una pulsación nueva de HP+HK permite unirse; hay que soltar los botones antes de jugar. Durante el combate se conservan las prioridades de comandos y relevos. La compatibilidad con un gabinete físico requiere otra validación.

El temporizador y las transiciones difíciles

MSHvsSF mantiene su ataque de equipo QCF + HP+HK. El modo sostenido usa QCB + HP+HK y consume el medidor disponible según las reglas investigadas de MVC1. En las pruebas, el contador recorrió 576, 575…0; otra activación con dos niveles y fracción 92 produjo 430 unidades. Son unidades de simulación, no segundos decimales.

Captura real de combined-06: etiquetas TIME y barras dibujadas por el juego, sin superposición. La comprobación del HUD se repitió en combined-08.

combined-06, activaciones escalonadas: queda solo el contador derecho. El reloj de ronda y los medidores normales se mantienen.

combined-08 corrige dos problemas concretos: HP+HK mantenidos al terminar el modo podían filtrarse al volver mediante un relevo; soltar los botones estando en el banco podía dejar un bloqueo pendiente y tragarse la siguiente pulsación. También evita la pausa inicial de los Hypers del propio equipo durante el modo, siguiendo la conducta verificada de MVC1 y Dreamcast.

Una prueba de guardado/restauración reprodujo los siguientes 300 callbacks, entradas, temporizadores y checksum de los 64 KiB de RAM. Esto no demuestra rollback de red. Se verificó un caso de KO del personaje activo y se compararon 7.600 registros de una secuencia; la matriz completa de derrotas y personajes sigue abierta. Una comparación histórica de QCF presentó 73 diferencias de campos en 70 callbacks: no se afirma identidad cuadro a cuadro con el juego original.

Una corrección concreta de entradas

El perfil local del emulador filtraba algunos cambios rápidos de dirección: P3/P4 en MVC1 y los cuatro controles en MSHvsSF podían pasar de Izquierda → Derecha o Arriba → Abajo y producir una entrada neutra. El perfil corregido conserva esos cambios entre muestras consecutivas y neutraliza únicamente las direcciones opuestas pulsadas a la vez.

Los controles ordenados entre mando y puerto pasan de 59/77 a 77/77 en MVC1 y de 43/77 a 77/77 en MSHvsSF. Durante Duo simultáneo en MVC1, llegan al puerto las 156 palabras solicitadas, frente a 118 antes. Se verificaron 2.461 muestreos completos y 1.337 entregas de entradas e historial a los luchadores, sin diferencias. La ROM no cambió para esta corrección; los registros fijan el emulador y las ROM usadas.

Esto aún no prueba que se conserven todas las pulsaciones breves. De las 156 solicitudes, 154 se leen y terminan en el mismo callback, una termina en el siguiente y una pulsación de P2 no tiene lectura física del luchador. No se añadió una cola de entradas. Los problemas concretos de Wolverine/Strider, el rollback de Fightcade y los controles físicos siguen siendo pruebas separadas.

El TIME azul original ya se dibuja en MSHvsSF

msh-exact-time-11 incorpora las 11 piezas del marco y las 16 máscaras de vaciado originales de MVC1. Conserva sus colores y usa dos contadores independientes. La comparación de los 32 MiB de gráficos confirma que solo cambiaron esas 27 piezas asignadas; no se amplió la memoria de gráficos.

Captura real en el callback 5500 de staggered11-latched. El dibujo pertenece al juego; no es una anotación del video.

Callback 6200: terminó el modo izquierdo. Las dos barras desaparecen al llegar al callback 6400.

Las 22.900 comparaciones de píxeles opacos en 14 capturas coinciden exactamente. El observador sigue los bancos físicos de objetos y su captura en VBlank, en lugar de asumir que el contador actual corresponde a la imagen mostrada. Los registros de esta versión fijan los hashes y los límites. En la expiración observada se restauran ambas filas de paleta; si hay un conflicto de paleta o falta espacio en la lista de objetos, el HUD opcional se omite.

La secuencia fija anterior sigue sin lograr un KO en 11: los luchadores del lado derecho quedan con un mínimo de 12 y 80 de vida. Esa ejecución, ko11, se conserva como cobertura fallida. El dibujo adicional cambia la relación entre callbacks y simulación; no se asumió que la secuencia anterior mantendría su resultado. Las capturas de 06/08 y el video de 03 conservan sus etiquetas.

Una secuencia nueva de controles normales sí alcanza un KO del personaje activo en la misma ROM de build11, sin modificarla. Spider-Man cae con ambos modos activos y 131 unidades en cada temporizador. Captain America pasa a ser el personaje activo del lado derecho en el siguiente callback. P4 lo mueve a la derecha e inicia un puñetazo débil nuevo: llegan las ocho muestras de movimiento y las cuatro de puñetazo solicitadas. Solo termina el modo del equipo de Spider-Man; el temporizador izquierdo continúa.

Los registros del KO y la recuperación en build11 comparan la ejecución original con una reproducción fija: coinciden los 7.600 registros de callbacks, salvo la etiqueta que identifica el método de control. Los objetos TIME pasan de dos barras a una, y después a ninguna al expirar el último temporizador; ambas filas de paleta recuperan sus valores guardados. Cada ejecución pasa 5.808 comprobaciones de dibujo y 6.908 de envío de objetos. Se ejecutaron sin ventana ni capturas nuevas y con el perfil histórico de observación; no amplían el resultado del nuevo filtro de direcciones.

Esto verifica un caso de KO y recuperación del control del superviviente. Siguen pendientes las rondas completas, revanchas, KOs simultáneos, la matriz de personajes, los escritores de paleta, las referencias gráficas calculadas y los límites de objetos y píxeles. No demuestra el comportamiento en gabinetes ni en red.

Por qué faltaban los meteoros

El fondo de MVC1 utiliza 866 piezas de 32×32. Dividirlas y reutilizar patrones de 16×16 permite una propuesta sin pérdida, pero exige 2.404 patrones nuevos. Los espacios aparentemente vacíos no están necesariamente libres: algunos forman zonas transparentes de los escenarios existentes.

Después de proteger las referencias observadas en una ejecución normal de MSHvsSF, quedan 2.381 espacios, 23 menos de los necesarios. Con el corpus completo de mapas recuperados, quedan 1.695. La primera distribución se rechaza porque alteraría escenarios. No se escribieron gráficos para esa propuesta. Hace falta otra distribución segura, además de resolver mapas, paletas, prioridades y restauración al finalizar el modo.

Lo que queda antes de lanzar

Las pulsaciones de un solo callback pueden ocurrir entre dos actualizaciones de un luchador; se ha observado pérdida de ese tipo de entrada en MVC1. Hay que resolverlo con pruebas del muestreo real, sin confundir callbacks de video con cuadros de simulación. También quedan personajes y formas, agarres, proyectiles, cruces, transformaciones, expiración durante supers, KO doble, revanchas y presupuesto de CPU/objetos.

El harness ahora verifica las líneas físicas, la procedencia de lecturas y el muestreo de cada personaje. Un perfil nuevo expone los controles nativos de ambos juegos y pasa 43 casos de interruptores por juego. Los builds fijan hashes, bytes originales, reservas y fuentes para poder reproducirlos.

El parche DHC es otro proyecto: añade cancels y relevos, no cuatro propietarios independientes. Publicar este informe permite mostrar el avance sin anunciar compatibilidad con gabinetes, Fightcade en línea o una versión final que todavía no existe.

Actualización del 22 de septiembre: los meteoros sí caben

Dos mediciones cambiaron el resultado. Primero, las ocho fases del desplazamiento resultaron ser un ciclo guionizado de 24 actualizaciones deducido del código, no un rango muestreado; y la auditoría que excluía 774 espacios asignaba cada lista de sprites al banco 0. Al corregir cada lista a su banco real, las 12.790 listas contabilizadas no producen ningún riesgo y quedan 2.235 espacios realmente libres.

Segundo, la geometría estaba planteada al revés. El mapa de origen mide 2.048 px de ancho y el de la capa anfitriona 1.024, así que nunca puede copiarse por posición. Empaquetar las ocho ventanas de fase en un atlas de ventanas —ocho celdas de 27×15 piezas, con el escritor de desplazamiento del port asignando fase a celda— requiere 2.012 piezas nuevas y 3.240 de 4.096 entradas de mapa.

Frente a 2.223 espacios libres, tras restar doce que ya ocupa una compilación hermana de Strider, el margen es de 211 espacios. Las 3.240 celdas del atlas se decodificaron de vuelta y se compararon con el render nativo: cero diferencias de píxel o de paleta. Los espacios quedan reservados en el registro de asignación compartido.

Esto era un plan de asignación, no un parche publicado: faltaba capturar la paleta real del fondo.

Actualización: los meteoros ya están en MSHvsSF (v2)

Las dos versiones v2 de MSHvsSF ya llevan el cielo. Conserva cuatro de las ocho ventanas de fase de MVC1 (0, 2, 4 y 6), cada una durante seis actualizaciones, en la posición que MVC1 muestra con más frecuencia; no reproduce el paralaje del escenario. La animación de paleta está completa: los 36 registros de la tabla de MVC1, uno cada cuatro actualizaciones. Cortar las cuatro ventanas en piezas de 16×16 y compartir las reflejadas exige 1.019 piezas, colocadas solo en bloques vacíos de Scroll 2 que protege el censo corregido; cada celda se decodifica de vuelta sin ninguna diferencia de color ni de paleta. El mapa, un búfer de paleta y el estado ocupan 16 KB de RAM de video que estaban a cero en todas las muestras de combate, y se limpian al terminar el modo. El cielo solo aparece mientras el modo temporizado de un equipo está activo, deja pasar los destellos blancos de los Hypers del juego y devuelve la pantalla a MSHvsSF cuando termina el último temporizador. Los Hypers normales conservan el fondo de MSHvsSF.

Las dos compilaciones se probaron en MAME con controles normales: un Hyper normal antes del modo, la activación, un Hyper con sus destellos dentro del modo, la activación del otro equipo con el primero aún activo, los dos finales y la limpieza. Para la de cuatro jugadores, el driver de dos jugadores de MAME recibió el cableado de cuatro mandos en sus puertos de entrada: se unieron los cuatro y P1 y P3 lanzaron cada uno un Hyper con su propio control dentro del modo. Ninguna v2 tiene todavía una grabación en FBNeo local.

Actualización: el ∞ de MVC1 (v3)

MVC1 cambia su dígito de nivel por un signo de infinito mientras dura su Duo, y las dos versiones v3 de MSHvsSF hacen ahora lo mismo durante el modo temporizado de cada lado. La propia rutina del HUD de MSHvsSF sigue dibujando el dígito: al final del código que escribe el nivel de cada lado, un gancho comprueba el bit de modo y el temporizador de ese lado y, mientras los dos están activos, escribe en su lugar el signo de dos piezas del propio MVC1, tres píxeles a la izquierda del dígito. El signo usa la paleta fija del HUD de MSHvsSF, los dorados de la etiqueta LEVEL, porque la paleta de los dígitos va cambiando; el dígito vuelve cuando termina el modo.

Las dos compilaciones v3 repitieron sus pruebas en MAME, y el medidor de cada cuadro muestreado se comparó con el estado del modo en ese cuadro. En la de 1 contra 1, 334 de 336 comprobaciones coincidieron y las otras 2 captaron la propia actualización del HUD justo después de un cambio. En la de cuatro jugadores coincidieron 223 de 228 y 1 captó el HUD a mitad de actualización; las otras 4 son dos cuadros sueltos en la escena más pesada probada (cuatro luchadores, dos Hypers a la vez y el cielo activo) en los que faltó todo el HUD inferior durante un cuadro. Es un efecto de los cuadros con retraso: la lista de sprites se fija antes de copiar los registros del HUD, y la v2 mide el mismo retraso en esa escena. Los clips y las imágenes de MSHvsSF se repitieron entonces con las ROM v3 y las mismas entradas.

Actualización del 24 de septiembre: XMvsSF, MSHvsSF v5 y MVC1 v2

▶ Play

X-Men vs. Street Fighter es el tercer juego, con dos versiones preliminares: 1 contra 1 con Duo (xmv-two-human-full-02, v3) y cuatro jugadores (xmv-four-human-full-02, v2). Los comandos son los mismos que en los otros dos: QCB + HP + HK para el modo temporizado, QCF + HP + HK para el Hyper de equipo (en XMvsSF se llama Variable Combination) y HP + HK para el relevo.

El inicio sigue el Variable Cross de MVC1: tu luchador hace su pose de llamada, su propia burla con su voz, y no se le puede golpear mientras dura; después se reproduce la pausa del Variable Combination de XMvsSF y el compañero entra desde detrás con su propio ataque de entrada. Mientras dura el modo de un lado, el cielo de meteoros de MVC1 sustituye al escenario, la barra TIME de MVC1 cuenta el modo de ese lado sobre su medidor de Hyper y el ∞ de MVC1 sustituye a su número de nivel. Dentro del modo los Hypers no tienen pausa ni coste, así que en el Duo un solo movimiento lanza los Hypers de los dos. Al acabarse el tiempo, el compañero se va y el luchador principal se queda.

Las dos compilaciones de XMvsSF se probaron en MAME 0.264 con controles normales: el Cross de ambos equipos, actualización por actualización, y las marcas, la barra TIME, el ∞, el cielo y las sombras en unos 41.000 cuadros con nueve alineaciones (Duo) y 52.000 con diez (cuatro jugadores), con los 17 personajes seleccionables. Esas pruebas de censo pusieron el medidor en nivel 3 con una escritura de análisis al empezar el combate; los clips, las imágenes y el tráiler salen de otras ejecuciones en MAME, solo con controles normales y sin escrituras de memoria.

MSHvsSF v5 empieza el modo como MVC1: la pose con su voz, el corte del Hyper de equipo de MSHvsSF con los retratos de los dos y, después, el compañero entra volando desde detrás con su ataque. Al empezar no se gasta medidor: se ve lleno mientras dura el modo y cuesta dos barras al terminar. La v5 también pone las marcas de MVC1: 1P y 2P en la de 1 contra 1, y de 1P a 4P sobre cada cabeza en la de cuatro jugadores. La v4 fue una compilación interna; todo lo que añadió está en la v5. MVC1 v2 conserva byte a byte los controles, la forma de unirse y el temporizador de la v1, y añade las marcas de 1P a 4P sobre cada luchador.

El tráiler es un montaje, no una prueba: cada toma es una de estas compilaciones preliminares ejecutándose en MAME, con controles normales y a la velocidad propia de CPS-2.

Qué significa «preliminar»

Las descargas son exactamente los archivos cuyos instaladores pasaron siete casos de PowerShell y el instalador en Python, y se compararon pieza por pieza con la ROM probada. Aparte de eso, cada paquete dice qué cubrieron sus grabaciones y qué no. Sigue abierto en los cinco: el plantel completo y las transformaciones, guardar y cargar, las revanchas, el peor caso de objetos y CPU, las pulsaciones de un solo cuadro, Windows nativo, cuatro mandos físicos, el cableado de gabinete y el juego en línea con rollback para cuatro. Nada de eso se afirma hasta que se haya probado.

Compártelo

Cross Fever en la placa arcade: cuatro jugadores en X-Men vs. Street Fighter, MSHvsSF y Marvel vs. Capcom, y el Duo de MVC1 con su pose, su entrada volando, el cielo de meteoros y el ∞ en el medidor. Instaladores gratuitos que solo contienen el parche. morphus56k.com/es/blog/cps2-four-player-cross-fever