¿Cómo funcionan los emuladores de PlayStation, Xbox, Windows...?

¿Qué es un emulador? ¿Un programa que "traduce" un dispositivo a otro, como si se convirtiera un archivo de .docx a .pdf? Si fuera tan fácil, tendríamos un emulador el mismo día del lanzamiento de cada consola, pero no es así. Lo esperamos durante años o nunca lo conseguimos. Es uno de los mayores retos de la programación.

Un emulador no es un simple convertidor, sino una versión de software del dispositivo completo. El procesador, la tarjeta gráfica, la memoria, el chip de sonido y el sistema operativo deben funcionar en perfecta sincronía, en tiempo real y con la precisión suficiente para que el juego o programa no note la diferencia.

¿Dónde comienza el desarrollo? ¿De dónde obtienen los desarrolladores la idea para desarrollar?

Los desarrolladores de emuladores casi nunca tienen acceso a la documentación técnica oficial del fabricante de la consola. Sony, Microsoft y Nintendo no comparten sus especificaciones internas; al contrario, protegen esta información como secreto comercial. Por eso, en la industria, cada proyecto comienza con lo que se conoce como "ingeniería inversa". Esto significa que los desarrolladores toman el hardware real, lo desmontan, analizan los circuitos electrónicos, interceptan las señales entre los chips y, poco a poco, reconstruyen el funcionamiento del procesador con cada comando del código del firmware (es decir, el software integrado directamente en el dispositivo).

Esto suele implicar un enfoque de «sala limpia». Un grupo analiza y documenta el funcionamiento del dispositivo, mientras que otro utiliza esta documentación, sin tener acceso al código original del fabricante, para escribir un nuevo programa que imite el mismo comportamiento. Esta separación no es solo una formalidad técnica, sino una garantía legal, ya que la emulación en sí no es ilegal, mientras que copiar el código propietario de un fabricante sí lo es. Además, los desarrolladores necesitan la BIOS o el firmware original de la consola, el programa de arranque básico que controla el hardware. Los usuarios suelen tener que obtenerlo por su cuenta, a menudo directamente de su propia consola, ya que no está permitido distribuirlo junto con el emulador.

Lo que un desarrollador necesita saber?

Si alguna vez has leído o leerás los diarios de desarrollo de emuladores como RPCS3 para PlayStation 3 o Eden para Nintendo Switch, te darás cuenta rápidamente de que dicho desarrollo requiere un equipo más grande, no solo una persona. Es necesario dominar una amplia gama de habilidades.

Requiere comprender la arquitectura del procesador, ya sea PowerPC (el procesador de Xbox 360), ARM, MIPS o x86, incluyendo todas sus instrucciones, registros y detalles de temporización. También requiere dominar el funcionamiento de la GPU y traducir sus instrucciones a interfaces gráficas modernas como Vulkan o DirectX. Esto incluye emular el chip de sonido, los controladores, la jerarquía de memoria y el sistema operativo de la consola, que gestiona archivos, subprocesos y permisos de acceso.

El mayor desafío técnico suele ser la recompilación dinámica, también conocida como compilación justo a tiempo (JIT). En lugar de que el emulador interprete cada comando de la consola original uno por uno, lo cual sería demasiado lento, traduce los comandos al código máquina del procesador anfitrión en tiempo real, ejecutándolos a una velocidad casi nativa. Esto requiere un conocimiento extremadamente preciso de ambas arquitecturas simultáneamente, y el resultado debe ser idéntico bit a bit al original; de lo contrario, el juego se congelará, fallará o mostrará gráficos incorrectos.

¿Por qué el desarrollo lleva años, a veces décadas?

La respuesta reside en gran medida en un único ejemplo: la PlayStation 3. Su procesador Cell, desarrollado conjuntamente por Sony, Toshiba e IBM, no era un procesador multinúcleo convencional, sino una única unidad de procesamiento principal (PPU) combinada con ocho unidades de procesamiento auxiliares especiales (SPU), cada una con su propia memoria local pequeña y sin acceso directo a la memoria principal del sistema. Los programadores de videojuegos tenían que dividir manualmente el trabajo entre estas unidades, ya que ningún compilador lo hacía automáticamente, lo que significaba que un emulador no podía simplemente compilar el código como lo haría para un procesador más convencional.

Debe comprender el propósito real del código extremadamente específico y optimizado manualmente. Los desarrolladores de RPCS3 tuvieron que crear un procesador que rompía casi todas las suposiciones de la arquitectura x86 sobre memoria, coherencia de datos e hilos, para obligar a sus programas a ejecutarse en un hardware que comparte pocas características con Cell. El primer prototipo del emulador disponible públicamente apareció en 2011, e incluso hoy, más de una década después, el equipo anuncia ocasionalmente avances en la optimización que solo ahora aceleran significativamente partes de juegos que antes no se ejecutaban o presentaban graves problemas.

La Xbox 360 presenta un desafío similar, aunque con algunas diferencias. El desarrollo del emulador Xenia comenzó en 2013 y logró lanzar su primer juego comercial con relativa rapidez, pero para 2018, los desarrolladores se estancaron en la emulación precisa de la GPU Xenos, lo que requirió casi tres años de reescritura completa del código gráfico antes de que el rendimiento mejorara significativamente. La razón de ciclos de desarrollo tan largos no es la pereza ni la falta de habilidad, sino el hecho de que el emulador debe comprender miles de casos límite, comandos especiales, errores en el hardware original que los desarrolladores de juegos explotaron de forma inconsciente o intencionada, y peculiaridades de sincronización que no se describen en la documentación porque, sencillamente, no existe documentación oficial.

Otro factor es la presión legal. Nintendo es particularmente conocida por ejercer presión legal. En febrero de 2024, presentó una demanda contra los desarrolladores del popular emulador Yuzu, alegando que este había eludido ilegalmente la protección de cifrado de la Switch, como lo demuestra el hecho de que Zelda: Tears of the Kingdom alcanzó un millón de descargas antes de su lanzamiento oficial.

Tropic Haze, la compañía detrás de Yuzu, aceptó un acuerdo de 2,4 millones de dólares y cerró el emulador por completo. Poco después, Nintendo contactó personalmente al desarrollador principal del proyecto competidor Ryujinx para detener su desarrollo, eliminar la organización y todos sus activos. Estos casos demuestran claramente por qué muchos desarrolladores talentosos prefieren trabajar con las consolas antiguas, consideradas más seguras, mientras que los proyectos más recientes suelen permanecer en el anonimato o fragmentados en varias bifurcaciones del mismo proyecto original.

¿Por qué algunas consolas son más difíciles de piratear que otras?

Por regla general, cuanto más se asemeje su arquitectura interna a la de un PC estándar, más fácil será emular una consola. La PlayStation 1 y 2 utilizan procesadores relativamente convencionales, por lo que se emularon relativamente pronto y hoy en día funcionan sin problemas incluso en hardware más modesto. Pero cuando los fabricantes incorporan sus propias soluciones no estándar, como Cell en la PS3, la complejidad aumenta exponencialmente. De forma similar, la Nintendo Switch, que se basa en un chip Tegra personalizado de Nvidia y tiene sus propias peculiaridades en la gestión de memoria y gráficos.

La situación se complica aún más con la última generación, la PlayStation 5 y la Xbox Series X/S, ya que se trata de sistemas con una arquitectura más similar a la de los ordenadores modernos (procesadores AMD Zen y gráficos RDNA), pero a la vez protegidos por mecanismos de seguridad mucho más avanzados que los disponibles para las generaciones anteriores. Actualmente, prácticamente no existe ningún emulador funcional para ninguna de estas dos consolas, puesto que los desarrolladores aún están descifrando las capas de seguridad básicas, lo que supone un reto mucho más complejo y lento que la emulación de hardware clásica.

¿Existen diferencias en la emulación entre teléfono y ordenador?

La emulación en dispositivos móviles presenta un obstáculo adicional que los usuarios suelen pasar por alto: la diferencia entre la arquitectura de procesador ARM, presente en casi todos los teléfonos, y la arquitectura x86, estándar en los ordenadores. Por lo tanto, al ejecutar un emulador de consola basado en x86 o PowerPC en un teléfono, el programa debe traducir simultáneamente las instrucciones de la arquitectura original a ARM, lo que supone una carga computacional adicional innecesaria en un ordenador, donde el procesador principal suele ser x86.

Además, hasta hace poco, Apple prácticamente había prohibido los emuladores en los iPhones. No fue hasta abril de 2024 que Apple permitió explícitamente los emuladores de consolas de videojuegos retro en las directrices de su App Store por primera vez, los cuales ahora también pueden ofrecer descargas de juegos. Antes de eso, la única forma de obtener emulación en un iPhone era mediante jailbreak o un método complejo a través de aplicaciones web.

Incluso después de este cambio, persisten algunas limitaciones. Por motivos de seguridad, iOS restringe estrictamente la compilación JIT, es decir, la generación dinámica de código máquina durante la ejecución del programa, que es la técnica principal para lograr una velocidad aceptable en emuladores más exigentes. Como resultado, muchos emuladores en el iPhone funcionan mucho más lento que el mismo proyecto en Android, donde estas restricciones prácticamente no existen y donde los desarrolladores han tenido un acceso más libre a los recursos del sistema durante muchos años.

¿Existe algún emulador de Windows? Winlator, GameHub, GameNative...

Si lees mis reseñas de teléfonos, notarás que suelo incluir pruebas de varios juegos de Windows, además de Android y Nintendo Switch. En este caso, el término "emulador" no es el más preciso técnicamente. Se trata más bien de un conjunto de capas de compatibilidad superpuestas.

Winlator es una aplicación gratuita de código abierto creada por un desarrollador apodado BrunoSX (brunodev85) que ejecuta aplicaciones y juegos de Windows (x86_64) directamente en dispositivos Android basados en ARM, sin BIOS, sin arrancar una copia real de Windows y sin una imagen de disco. En cambio, Winlator combina dos tecnologías distintas, cada una resolviendo una parte del problema. La primera es Wine, un proyecto muy conocido que lleva décadas traduciendo las llamadas a la API de Windows (comandos para abrir archivos, acceder al registro, dibujar gráficos mediante Direct3D o reproducir audio) a comandos que el kernel de Linux sobre el que se ejecuta Android en segundo plano entiende.

La segunda tecnología es Box86 o Box64, que realiza una tarea aún más fundamental. Traduce las instrucciones del procesador de la arquitectura x86 a la arquitectura ARM en tiempo real, ya que ningún teléfono tiene físicamente un procesador x86. Además, cuenta con una capa gráfica. Winlator utiliza el controlador Mesin Turnip para las GPU Adreno y las herramientas DXVK y VKD3D, que traducen las llamadas de DirectX a Vulkan, de forma similar a como lo hace Proton en Linux.

El usuario crea un llamado contenedor dentro de la aplicación, una especie de entorno virtual aislado en el que configura la resolución, la cantidad virtual de VRAM, el número de núcleos del procesador y los controladores por separado para cada juego o programa.

Dado que se realizan dos traducciones consecutivas (primero llamadas a la API y luego comandos del procesador), la carga sobre el hardware del teléfono es mucho mayor que con la emulación de consola clásica. Esta es también la razón por la que Winlator ejecuta juegos antiguos o menos exigentes relativamente bien, pero con juegos AAA modernos con motores gráficos exigentes como Unreal Engine, a menudo se producen tirones en la compilación de sombreadores y un calentamiento significativo del dispositivo. Hasta ahora, el RedMagic 11S Pro ha gestionado mejor el calor, pero para ello tuvo que usar un ventilador y refrigeración líquida.

¿GameHub y GameNative son diferentes?

Cuando Winlator alcanzó suficiente popularidad, comenzaron a surgir competidores a su alrededor, utilizando básicamente la misma receta tecnológica (Wine, Box64, Vulkan), pero diferenciándose en la facilidad con la que se presentaba todo.

GameNative surgió del proyecto Pluvia, un cliente no oficial de Steam que permitía a los usuarios iniciar sesión en su cuenta de Steam a través de Winlator y ejecutar juegos directamente desde su biblioteca sin tener que buscar manualmente los archivos de instalación en línea. GameNative se creó como un derivado del proyecto Pluvia y actualmente se desarrolla de forma más rápida y activa que el proyecto original.

GameHub tiene un origen ligeramente diferente. La aplicación, antes conocida como GameFusion, es de Gamesir, fabricante chino de mandos para videojuegos, y su principal ventaja es su comodidad. Es compatible con el inicio de sesión de Steam, algo que Winlator, la aplicación oficial, no permite de forma predeterminada, y también admite la vibración en los mandos. Dado que es un producto de un fabricante de hardware chino, surgieron preocupaciones sobre la privacidad en la comunidad, por lo que se creó una versión llamada GameHub Lite sin seguimiento integrado.

¿Es mejor emular el resultado o el dispositivo completo?

Los emuladores no siempre necesitan recrear cada transistor del sistema original. A menudo utilizan un enfoque de emulación de alto nivel (HLE). En lugar de emular un componente de hardware o software del sistema completo con todo detalle, el emulador reconoce lo que el juego pretende lograr y realiza la misma función con su propia implementación.

Lo contrario es la emulación de bajo nivel (LLE, por sus siglas en inglés), donde el desarrollador intenta acercarse lo máximo posible al comportamiento real del hardware o firmware original.

HLE puede ser mucho más rápido. El problema surge cuando el juego no utiliza una función según lo previsto. Si un desarrollador descubre una peculiaridad no documentada del sistema real y la explota intencionadamente, una elegante implementación de HLE podría hacer lo "lógicamente correcto", mientras que la consola original hacía algo completamente diferente.

¿Por qué un juego funciona perfectamente mientras que otro ni siquiera arranca?

Si un emulador puede emular una PlayStation 2, ¿qué importa qué juego de PS2 ejecute? Porque no hay dos juegos que utilicen la consola exactamente de la misma manera.

Un juego puede usar solo las características gráficas más comunes, mientras que otro utiliza una "mezcla" inusual. Uno usa cálculos de coma flotante estándar, otro se basa en un esquema de redondeo muy específico. Uno usa un mando estándar, otro un micrófono o un accesorio especial. Un tercero puede contener un motor de carreras cuyo funcionamiento depende, inadvertidamente, de la sincronización precisa de un evento del procesador.

Por lo tanto, probar un emulador no es lo mismo que probar una aplicación normal. Una buena prueba de regresión consiste en una biblioteca de cientos o miles de juegos.

Y entonces llega un parche que por fin consigue que un juego funcione correctamente, pero estropea otros tres.

Irónicamente, la "falsificación" suele ser mejor que la original.

Cuando un emulador es lo suficientemente preciso, puede ocurrir que el juego emulado se vea y funcione mejor que el original.

Un juego diseñado para 480p puede renderizarse en 1440p o 4K mediante un emulador. Este puede renderizar la geometría a una resolución nativa superior, mejorar el filtrado de texturas, usar técnicas modernas de suavizado de bordes, corregir la relación de aspecto y, en algunos casos, eliminar el límite de velocidad de fotogramas original. El emulador ofrece guardado rápido, rebobinado, texturas alternativas, correcciones y modificaciones que no existían en la consola original.

A veces el emulador funciona mejor en Linux que en Windows.

Muchos emuladores y capas de traducción, como Proton, funcionan mejor en Linux. La explicación reside principalmente en cómo el sistema operativo se comunica con el hardware. Vulkan, una interfaz gráfica moderna y abierta, ofrece un menor consumo de CPU y un control más directo sobre la tarjeta gráfica que los métodos más antiguos, pero aún comunes, en Windows. Además, los controladores de Linux para Vulkan han madurado en los últimos años hasta el punto de que suelen tener una menor sobrecarga del sistema que los de Windows.

Además, la herramienta DXVK, que forma parte de Proton, traduce las llamadas de DirectX a Vulkan en tiempo real, lo que suele ser sorprendentemente más rápido que si Windows ejecutara directamente la llamada nativa de DirectX, ya que evita ciertas capas del sistema operativo que simplemente no existen en Linux. Linux también permite una menor latencia en la comunicación entre procesos y una planificación de subprocesos más predecible dentro del núcleo del sistema, lo que supone una valiosa ventaja para los emuladores que deben coordinar docenas de tareas paralelas en cada fotograma.

Para adentrarse en el desarrollo de emuladores, hay que ser un maestro y estar loco al mismo tiempo.

Mientras haces malabares con comandos de CPU, llamadas a API, mecanismos de seguridad y esperas en silencio que Sony y Nintendo no llamen a tu puerta, también tienes que soportar las altas expectativas de la comunidad para la que desarrollas un emulador sin esperar nada a cambio. Sin embargo, una minoría muy ruidosa suele tener expectativas excesivamente altas e infundadas, creyendo que desarrollar este tipo de software es relativamente fácil. Si existe un emulador para la Nintendo Switch, desarrollar uno para la Nintendo Switch 2 no debería ser tan difícil, ¿verdad?

Cada nuevo avance implica meses de búsqueda de errores, lectura de volcados hexadecimales de código máquina e intentos de comprender las decisiones de los ingenieros actuales y del pasado que escribieron código hace veinte años sin pensar que alguien intentaría recrearlo en un hardware completamente diferente.

La combinación de obstinación, curiosidad y amor por preservar el legado de los videojuegos es lo que hace que la emulación exista en primer lugar, y la razón por la que la lucha por cada nueva generación de consolas comenzará prácticamente desde cero.