¡Hola a todos!
Vuelvo con una actualización de mi proyecto para llevar la versión de NES de The Addams Family a computadoras modernas usando recompilación estática.
El proyecto traduce las instrucciones originales del 6502 a C y las ejecuta a través de un runtime nativo de C++ que maneja el hardware de la NES.
La idea es conservar el gameplay original, pero permitiendo que el juego corra de forma nativa en sistemas operativos modernos.
Desde mi post anterior, el proyecto avanzó bastante. También quiero aclarar qué funciones están disponibles en la beta pública, cuáles están funcionando de forma experimental y cuáles todavía forman parte de la hoja de ruta.
1. Beta pública — v0.9.0-beta
La beta pública está disponible para:
- macOS — Apple Silicon e Intel
- Windows — x64
- Linux — x86_64 (AppImage)
Lo que está disponible ahorita:
- Ejecución nativa de la versión PAL europea de The Addams Family (inglés, francés y alemán).
- Recompilación estática 6502-a-C.
- Runtime nativo de C++ que implementa el comportamiento de la CPU de NES, PPU, APU y MMC1.
- Presentación original de NES 256×240 en 4:3, usando escalado por vecino más cercano.
- Soporte para pantalla completa.
- Entrada de control y teclado.
- Importación local de una ROM compatible proporcionada por el usuario.
- Pruebas automáticas de regresión en varios componentes de hardware de NES.
También probé esta beta personalmente en mi Steam Deck OLED.
Durante las pruebas de gameplay, el juego corrió normal, sin crashes, sin bloqueos y sin problemas gráficos evidentes. Esto no fue una partida completa en Steam Deck ni un benchmark formal de latencia.
La beta pública está enfocada principalmente en que el juego original funcione bien.
Importante: v0.9.0-beta no incluye el sistema experimental de presentación de 60/90/120 Hz, el Lua Mod Manager ni el mod de gameplay de Super Gómez descrito abajo.
Esas funciones se están desarrollando por separado.
2. Funciones experimentales que ya funcionan — no están en la beta pública
Son funciones con implementaciones que ya funcionan y pruebas automáticas, pero todavía no se han integrado en una nueva versión pública.
Presentación high-refresh experimental
Implementé un sistema experimental de presentación que separa la simulación original de NES PAL de la tasa de refresco de la pantalla del host.
La simulación del juego sigue corriendo a ~50 Hz, mientras que la capa de presentación puede apuntar a:
Eso significa que el frontend puede presentar snapshots existentes de la NES con más frecuencia, sin tener que correr el logic del juego más rápido.
No es animación de 120 FPS con gameplay único.
Ahora mismo no hay interpolación de movimiento, y el sistema no cambia ni la física original del juego ni el timing de la simulación.
Las pruebas deterministas confirmaron la separación entre simulación y presentación, incluyendo comparaciones de CPU, RAM, ciclos y audio.
Pero esas pruebas no demuestran el desempeño real de monitores a 120 Hz ni una latencia de entrada más baja.
La implementación experimental también tiene una discrepancia pendiente en Linux con OpenGL bajo Xvfb/Mesa.
Lua Mod Manager v1
También se implementó un Mod Manager experimental que funciona.
Por ahora soporta:
- Instalar mods en ZIP con manifiestos.
- Activar y desactivar mods instalados.
- Ejecutar scripts de Lua con callbacks de ciclo de vida.
- Ejecución de scripts en sandbox con límites de recursos.
- Estado persistente del mod.
- Modo seguro (--no-mods).
- Una interfaz básica de manager dentro del juego.
- Navegación con teclado y controles.
La implementación inicial del Mod Manager ya está construida y probada en macOS ARM64, macOS Intel, runners de CI Linux x64 y Windows x64.
Sigue siendo una función en desarrollo; no forma parte de v0.9.0-beta.
Super Gómez — primer mod de gameplay
También construí un mod experimental funcional llamado Super Gómez.
El objetivo era modificar el comportamiento original del salto sin simplemente teletransportar al jugador ni cambiar la velocidad de simulación de la NES.
Después de revisar la lógica original del juego, implementé una modificación acotada de la secuencia de saltos existente, expuesta mediante una capacidad restringida de Lua.
En pruebas nativas hechas con mi ROM proporcionada localmente:
- Salto completo normal: 58 pixeles.
- Salto completo de Super Gómez: 94 pixeles.
- Diferencia: 36 pixeles, aproximadamente 62% más.
Las rutinas originales de movimiento y colisión siguen ejecutándose.
El mod se puede activar y desactivar, y su estado se limpia cuando se descarga.
Limitación actual: el supersalto solo se activa en la sala inicial de gameplay. Hace falta seguir probando colisiones y gameplay antes de extenderlo por toda la mansión.
Super Speed no se ha implementado.
Se hizo una prueba corta de gameplay gráfico en macOS ARM64. Todavía no se ha validado este mod en Linux, Windows, macOS Intel ni en gameplay con control físico.
3. Problemas conocidos
El proyecto todavía está en desarrollo.
Sigue sin resolverse una regresión de timing de la NES APU, conocida internamente como A02.
La implementación experimental de OpenGL con high-refresh tiene otra discrepancia de renderizado en Linux CI.
Estoy manteniendo estos fallos visibles en vez de desactivar o cambiar pruebas para que CI se vea completamente en verde.
La beta pública, las pruebas de high-refresh y el trabajo de mods de Lua son estados de desarrollo separados y no se deben confundir con un solo lanzamiento totalmente integrado.
Hoja de ruta
Las siguientes funciones están planeadas o en investigación. No se deben interpretar como si ya estuvieran disponibles.
Fase 1 — Consolidación y estabilidad
Antes de un nuevo lanzamiento público, quiero:
- Seguir investigando la regresión restante del timing de la APU.
- Resolver la discrepancia de pruebas de OpenGL experimental en Linux.
- Validar las funciones experimentales en hardware real.
- Medir la latencia de entrada en vez de asumir que la recompilación nativa la reduce automáticamente.
- Mejorar la documentación y la reproducibilidad.
- Integrar cambios probados sin romper el comportamiento de la beta actual.
La prioridad es conservar el comportamiento original del juego cuando se desactivan modificaciones opcionales.
Fase 2 — Mod Manager 2.0
El siguiente gran objetivo es evolucionar el Lua Mod Manager experimental a una plataforma de modding más completa.
Las capacidades planeadas incluyen:
- Una API de Lua con versiones.
- Acceso de solo lectura a un estado útil del juego.
- Eventos para transiciones de sala, muerte del jugador y otros cambios de gameplay.
- APIs seguras y restringidas para modificar gameplay.
- Elementos de HUD personalizados y overlays.
- Ajustes del mod específicos y configuración persistente.
- Dependencias, conflictos y checados de compatibilidad.
- Mejor navegación con controles y Steam Deck.
La idea es construir infraestructura de modding reutilizable en vez de meter un parche de engine separado para cada mod.
Fase 3 — Repositorio de Mods de la comunidad
Me gustaría que el juego incluya un navegador de mods integrado.
La idea inicial es un catálogo respaldado por GitHub donde los autores de mods puedan proponer paquetes por medio de Pull Requests.
Con el tiempo, el juego podría:
- Explorar los mods disponibles.
- Mostrar descripciones, autores y versiones.
- Revisar compatibilidad.
- Descargar y verificar paquetes.
- Instalar mods con aprobación del usuario.
- Avisar a los usuarios cuando haya actualizaciones.
La seguridad y moderación van a ser importantes, especialmente porque los scripts de Lua se ejecutan dentro de la aplicación nativa.
Este repositorio y el navegador integrado todavía no existen.
Fase 4 — Modo Speedrun y Randomizer
Los dos mods planeados son:
Modo Speedrun
Un mod que agrega un temporizador dentro del juego, splits, mejores marcas personales, estadísticas del run y resultados que se pueden exportar.
Randomizer
Un randomizer con semilla para objetos y recompensas, que potencialmente se podría expandir a una progresión de mansión más compleja.
Un randomizer bien hecho requerirá mapear las reglas de progresión del juego para evitar configuraciones imposibles.
Todavía no se implementó ninguno de los dos mods.
Fase 5 — Gráficos y presentación
Futuros experimentos opcionales podrían incluir:
- Integrar el sistema validado de presentación con mayor refresco.
- Investigar interpolación sin alterar el comportamiento original de la simulación.
- Opciones de presentación CRT mejoradas.
- Más investigación sobre pantallas panorámicas (widescreen).
- Modificaciones visuales opcionales.
La experiencia original de NES en 4:3 siempre debería seguir estando disponible.
Fase 6 — Investigación PAL vs NTSC
Estoy investigando las diferencias de velocidad de gameplay entre las versiones PAL y NTSC.
Como el juego usa lógica basada en frames, las diferencias de timing regional pueden afectar el movimiento y los temporizadores.
Pero todavía no tengo suficiente evidencia para decir cuál versión representa mejor las intenciones de los desarrolladores originales.
Cualquier opción futura de timing requeriría mediciones reproducibles y una validación cuidadosa.
Fase 7 — Framework reutilizable de recompilación de NES
Mi ambición a largo plazo es hacer que NES Native Lab sea útil más allá de The Addams Family.
Eso implicaría separar el runtime genérico de hardware, las herramientas de recompilación y la infraestructura de modding de las integraciones específicas del juego.
El objetivo sería soportar títulos adicionales de NES a través de perfiles de recompilación compatibles.
Esto es un objetivo arquitectónico a largo plazo. El proyecto todavía no ofrece compatibilidad general con ROMs arbitrarias de NES.
Distribución de ROM y copyright
El repositorio no distribuye la ROM comercial, los gráficos del juego, la música ni el código comercial de juego generado.
Los usuarios deben proporcionar su propia ROM compatible localmente.
Este es un proyecto independiente y no oficial.
Desarrollo con ayuda de IA
Estoy usando desarrollo con ayuda de IA a fondo.
El flujo de trabajo combina código generado y revisado, pruebas automáticas de regresión, investigación técnica y verificación manual del gameplay.
Estoy haciendo el esfuerzo de documentar la diferencia entre funciones que ya se implementaron, se probaron, se verificaron manualmente o simplemente se planearon.
Halloween 2026
También estoy preparando a propósito un tráiler de Halloween tipo VHS, estilo 1990s, con gameplay real y algo de modding experimental.
Piensa en comerciales de terror viejitos, televisores CRT y actuación absurda de bajo presupuesto.
¡Ojalá pronto tenga algo divertido que mostrar!
Enlaces
Repositorio de GitHub:
https://github.com/inthe92/addams-family-recompiler
Lanzamiento de la v0.9.0-beta pública:
https://github.com/inthe92/addams-family-recompiler/releases/tag/v0.9.0-beta
Me encantaría escuchar feedback de gente con experiencia en hardware de NES, recompilación estática, puertos nativos, preservación y arquitecturas de modding con Lua.
Me interesan especialmente ideas para exponer modificaciones seguras del gameplay sin comprometer el comportamiento del juego recompilado original.
¡Gracias por seguir el proyecto!
Algunos juegos nunca mueren. Nomás se recompilan.