⏱️ Lectura: 17 min
Dreaming Sarah, un plataformero 2D pensado solo para PS5, corre a 60 fps estables en una GTX 1050 Ti con un i5-7500 a 3.4 GHz. Lo logra sin emulador: AnyPS5 aplica un port layer sin emulación que reescribe el ejecutable de la consola para que hable el idioma nativo de Windows o Linux.
📑 En este artículo
- TL;DR
- ¿Qué es un port layer sin emulación?
- AnyPS5: el relinker que no necesita máquina virtual
- Cómo funciona el relinker: de ejecutable de PS5 a binario nativo
- Reimplementando las bibliotecas de sistema: qué es una PRX
- El recompilador de shaders: de GNM a SPIR-V
- Ejemplos prácticos: lo que ya corre en AnyPS5
- Cómo empezar
- Casos de uso reales
- Errores comunes y buenas prácticas
- Comparativa con alternativas
- Profundizando
- Preguntas frecuentes
- ¿Qué diferencia a AnyPS5 de un emulador de PS5?
- ¿Un port layer sin emulación funciona con cualquier juego de PS5?
- ¿Por qué AnyPS5 necesita reimplementar las bibliotecas PRX en vez de copiarlas?
- ¿Qué pasa si AnyPS5 encuentra una función del sistema que no conoce?
- ¿Es legal usar AnyPS5 con mis propios juegos de PS5?
- Referencias
La técnica recuerda a Proton, la capa que usa Valve para correr juegos de Windows en Linux sin traducir instrucciones de CPU: en ambos casos el procesador de origen y el de destino comparten arquitectura, y lo que cambia es el sistema operativo y sus bibliotecas. AnyPS5 aplica esa misma lógica a una consola por primera vez de forma pública.
TL;DR
- Un port layer sin emulación traduce el binario una sola vez: no interpreta instrucciones de CPU en cada frame.
- AnyPS5 reimplementa las bibliotecas de sistema PS5 (PRX) como código nativo para Windows y Linux.
- Dreaming Sarah corre a 60 fps estables en una GTX 1050 Ti con un i5-7500 a 3.4 GHz.
- El recompilador de shaders de AnyPS5 convierte el código gráfico de PS5 a SPIR-V, validado con Spirv-Tools.
- La licencia GPL-2.0 exclusiva obliga a que cualquier mejora al relinker o a una PRX reimplementada se mantenga abierta.
¿Qué es un port layer sin emulación?
Un port layer sin emulación es una capa de software que convierte un ejecutable de un sistema a otro reescribiendo su formato binario y sustituyendo las bibliotecas de sistema originales por implementaciones nativas, sin traducir instrucciones de CPU en tiempo real como hace un emulador tradicional.
La diferencia frente a un emulador como RPCS3, que reproduce la PS3, es la arquitectura de CPU. El procesador Cell Broadband Engine de la PS3 no tiene nada en común con un procesador de PC, así que cada instrucción debe traducirse en tiempo real. La PS5, en cambio, monta una APU con núcleos AMD Zen 2, la misma familia x86-64 que corre en cualquier computadora de escritorio moderna. No hay arquitectura que traducir: solo queda resolver el formato del ejecutable y las bibliotecas que el juego espera encontrar.
Esa similitud de arquitectura es la condición necesaria para que un port layer funcione. Si la CPU de origen y la de destino no coincidieran, relinkear el binario no alcanzaría; haría falta un emulador completo o, como mínimo, un recompilador estático que traduzca cada instrucción a su equivalente en la arquitectura destino.
AnyPS5: el relinker que no necesita máquina virtual
AnyPS5 es un proyecto open source que porta automáticamente ejecutables de PS5 a Linux y Windows. Su repositorio en GitHub acumulaba 7.400 estrellas, 554 forks y 103 observadores al 7 de octubre de 2026.
El README lo resume de forma directa. Incluye un relinker que convierte el ejecutable al formato nativo del sistema destino y una implementación de las bibliotecas de sistema PRX necesarias para el enlazado dinámico, sin emulación ni un proceso de runtime separado.
El proyecto mide su propio avance con un porcentaje: cuántas funciones de las bibliotecas de sistema declaradas en core/libs/prx ya están implementadas, no cuántas funciones existen en total en el sistema operativo de PS5. Ese matiz importa porque el número crece a medida que se declaran más funciones, no solo cuando se implementan las que ya se conocían.
El código se distribuye bajo licencia GPL-2.0 exclusivamente, lo que obliga a cualquier fork o producto derivado a mantenerse abierto. Ese es exactamente el principio detrás de AnyPS5: un port layer sin emulación aplicado a una consola en lugar de a otro sistema operativo de PC.
flowchart TD
A["Ejecutable de PS5"] --> B{"Misma arquitectura de CPU que el PC?"}
B -->|"No, ej. Cell de PS3"| C["Emulador: traduce instrucciones en cada frame"]
B -->|"Si, PS5 usa x86-64"| D["Port layer: relinkea el binario una sola vez"]
C --> E["Codigo nativo simulado, costo constante"]
D --> F["Ejecutable nativo real, sin traduccion en tiempo real"]Cómo funciona el relinker: de ejecutable de PS5 a binario nativo
Un juego de PS5 se distribuye en un formato ejecutable propio de Sony, derivado de ELF, pensado para que el kernel de la consola lo cargue y resuelva sus referencias contra las bibliotecas del sistema operativo de PS5. El relinker de AnyPS5 toma ese binario y lo reescribe como un ejecutable nativo (un PE en Windows o un ELF estándar en Linux), apuntando cada llamada a función de sistema hacia la implementación propia del proyecto en lugar de hacia el kernel original.
La operación ocurre una sola vez, antes de ejecutar el juego, no en cada instrucción durante la partida. Es la diferencia práctica frente a un emulador: un emulador interpreta o traduce código en el momento en que corre, instrucción por instrucción, lo que añade una capa de cómputo constante. El relinker de AnyPS5 produce un binario que el sistema operativo destino puede ejecutar directamente, con el mismo costo de arranque que cualquier programa nativo.
En términos concretos, cada referencia del binario original a una función de sistema (por ejemplo, una llamada para leer el mando o abrir un archivo) queda resuelta como un símbolo que apunta a la dirección de una función escrita por el proyecto, no a la dirección donde esa función vivía dentro del firmware de PS5. Si esa función todavía no fue reimplementada, el símbolo simplemente no existe y el programa falla al cargar o al llamarla, en vez de producir un comportamiento indefinido.
Reimplementando las bibliotecas de sistema: qué es una PRX
PRX es el formato de biblioteca dinámica que usan las consolas PlayStation desde la PS3: un módulo cargable que expone funciones del sistema operativo, de la misma forma en que una DLL las expone en Windows o una .so en Linux. Cuando un juego de PS5 llama a una función de red, de almacenamiento o de entrada, en realidad está llamando a una función dentro de una PRX del sistema.
AnyPS5 no copia esas bibliotecas (no podría: son propiedad de Sony), sino que reimplementa cada función desde cero, replicando el comportamiento esperado. Es trabajo de ingeniería inversa función por función, y por eso el proyecto lo mide en porcentaje de cobertura: cada función nueva que se documenta y se implementa amplía la lista de juegos que pueden arrancar sin tropezar con una llamada desconocida.
Cuando el juego llama a una función que todavía no existe en esa reimplementación, AnyPS5 no intenta adivinar ni seguir corriendo con un comportamiento aproximado. Lanza una excepción std::runtime_error, imprime el mensaje en la salida de error estándar y termina el proceso, según documenta el repositorio del proyecto.
flowchart LR
A["Ejecutable de PS5"] --> B["Relinker de AnyPS5"]
B --> C["Binario nativo (ELF o PE)"]
B --> D["Llamadas a funciones de sistema"]
D --> E["Implementacion propia de PRX"]
C --> F["Proceso nativo en Windows o Linux"]
E --> FEl recompilador de shaders: de GNM a SPIR-V
Los juegos de PS5 dibujan sus gráficos con GNM, la API gráfica de bajo nivel propia de Sony, usando shaders compilados para esa plataforma. Para que esos shaders corran sobre una GPU de PC, AnyPS5 incluye un recompilador que traduce el código gráfico original a SPIR-V, el formato intermedio que usan Vulkan y otras APIs modernas.
El proyecto puede compilarse con la bandera ANYPS5_ENABLE_SPIRV_TOOLS, que valida cada shader recompilado contra Spirv-Tools, la herramienta oficial de Khronos para verificar que un módulo SPIR-V es válido antes de enviarlo a la GPU. No hay forma directa de verificar desde afuera si un shader concreto pasó esa validación sin compilar el proyecto con esa bandera activada, porque el resultado depende del shader puntual que use cada juego.
💭 Clave: la traducción de shaders es la parte del port layer que más se parece a una emulación parcial: el código de la GPU sí se recompila a otro lenguaje, aunque el binario de la CPU no se traduzca en tiempo real.
Ejemplos prácticos: lo que ya corre en AnyPS5
La prueba pública más citada del proyecto es Dreaming Sarah, un plataformero 2D que corre a 60 fps estables combinando una GTX 1050 Ti con un i5-7500 a 3.4 GHz: hardware de gama media de hace varios años, no una GPU de última generación. Eso importa porque confirma que el costo del port layer en sí mismo es bajo, ya que el relinker no agrega una capa de traducción constante que consuma ciclos de CPU en cada frame.
Para el control, AnyPS5 soporta cualquier mando mapeado por SDL, incluyendo sticks analógicos y gatillos, y permite configurar teclado y mouse mediante un archivo anyps5-input.ini. Es la parte del proyecto menos exótica: una vez que el ejecutable corre nativo, mapear entrada es un problema resuelto muchas veces en otros proyectos de compatibilidad.
La lista pública de juegos verificados todavía es corta, y eso es consistente con un proyecto que crece función por función de PRX en lugar de replicar el sistema completo de una vez. El propio repositorio mantiene una lista de compatibilidad separada para rastrear qué títulos arrancan y con qué problemas conocidos.
Cómo empezar
AnyPS5 es un proyecto de C++ con CMake y varios submódulos de terceros en la carpeta 3rdparty, así que la clonación tiene que incluir esos submódulos. El README no detalla en texto plano qué SDK gráfico o versión de compilador exige cada plataforma, así que antes de compilar conviene revisar las instrucciones de build del propio repositorio, que es la fuente que se actualiza cuando cambian los requisitos.
git clone --recursive https://github.com/boykopovar/AnyPS5.git
cd AnyPS5
cmake -B build -S .
cmake --build build --config ReleaseEste flujo clona el repositorio con sus submódulos, genera los archivos de build con CMake y compila en modo Release. Funciona igual en Windows y en Linux porque CMake abstrae el generador (Visual Studio, Ninja o Make) según la plataforma; lo que cambia entre sistemas son las herramientas de compilador instaladas previamente, no los comandos de CMake. AnyPS5 además necesita un ejecutable de PS5 obtenido legalmente por el propio usuario: el proyecto no distribuye ni requiere software protegido por derechos de autor.
Casos de uso reales
El propio README encuadra el proyecto en cuatro usos: interoperabilidad, investigación, preservación y compatibilidad. Preservación es la palabra clave para un catálogo de consola que, como todo hardware, eventualmente deja de fabricarse y de repararse; un port layer que permite correr esos binarios en hardware de PC estándar extiende la vida útil del software mucho después de que la consola original se vuelva difícil de mantener.
Investigación e interoperabilidad apuntan a un uso distinto: entender cómo está construido el sistema operativo de una consola cerrada documentando, función por función, qué hace cada parte de su biblioteca de sistema. Ese conocimiento, publicado como código bajo GPL-2.0, sirve tanto para este proyecto como para cualquier otro esfuerzo de compatibilidad que necesite la misma información.
⚠️ Ojo: AnyPS5 no incluye, distribuye ni requiere firmware, claves criptográficas ni bibliotecas propietarias de Sony. Cada usuario es responsable de que los binarios que use provengan de una fuente legal según las leyes de su país y los términos de licencia del software original.
Errores comunes y buenas prácticas
El error más común al evaluar este tipo de proyecto es compararlo con un emulador en términos de expectativas de compatibilidad. Un emulador maduro como RPCS3 lleva más de una década replicando el comportamiento completo de una consola instrucción por instrucción; AnyPS5 crece juego por función reimplementada, así que la lista de títulos que arrancan sin errores todavía es corta y depende de cuántas funciones de PRX estén cubiertas.
Otro malentendido es asumir que, si el juego corre, corre completo. El propio proyecto documenta que cualquier estado no soportado lanza una excepción y termina el proceso de inmediato, sin comportamiento silencioso ni corrupción de datos que pase inadvertida. Es una decisión de diseño defendible, pero significa que un juego puede avanzar varias escenas y después cerrarse sin aviso previo al llegar a una función todavía no implementada.
Un gotcha adicional es asumir que cualquier GPU sirve. El recompilador de shaders produce SPIR-V pensado para correr sobre Vulkan, así que la tarjeta gráfica y sus drivers necesitan soporte Vulkan razonablemente actualizado; una GPU sin ese soporte no tiene forma de ejecutar el shader recompilado, independientemente de qué tan bien esté relinkeado el resto del ejecutable.
Buena práctica antes de intentar un juego nuevo: revisar la lista de compatibilidad del proyecto y qué tan cubiertas están las bibliotecas que ese juego usa más (gráficos, red, almacenamiento), en vez de asumir que todo el catálogo de PS5 se comporta igual.
Comparativa con alternativas
Un port layer sin emulación no es la única forma de llevar software de un sistema a otro. La tabla compara las cuatro estrategias más comunes y en qué condición de hardware tiene sentido elegir cada una.
| Opción | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
| Emulación completa (RPCS3) | CPU de origen y destino con arquitecturas distintas | Compatibilidad amplia sin reimplementar cada juego por separado | Costo de traducción en tiempo real, exige hardware potente |
| Wrapper de compatibilidad (Proton/Wine) | Mismo sistema operativo base, misma arquitectura de CPU | Reimplementa APIs una vez, no el binario de cada aplicación | Depende de cuántas APIs del sistema original estén cubiertas |
| Port layer de relinking (AnyPS5) | Misma arquitectura de CPU, consola con bibliotecas propietarias | Sin capa de traducción en tiempo real, rendimiento cercano al nativo | La cobertura de funciones de sistema crece función por función |
| Recompilación estática offline | Se puede analizar el binario completo antes de ejecutarlo | Optimiza el código generado por adelantado | Frágil ante binarios que generan código en tiempo de ejecución |
Profundizando
Relinkear un ejecutable no es solo cambiar la cabecera del archivo. Cada llamada a función de sistema usa una convención de llamada (qué registros o posiciones de la pila llevan los argumentos) y un diseño de memoria que el kernel original de PS5 esperaba. El relinker tiene que preservar esa convención en el lado de la aplicación mientras resuelve cada símbolo contra la implementación nativa correspondiente, así que el trabajo real está en mapear función por función, no en una sola conversión genérica de formato.
La licencia GPL-2.0 exclusiva también es una decisión técnica indirecta: cualquier mejora al relinker o a una biblioteca PRX reimplementada vuelve al proyecto si se distribuye, lo que en teoría acelera el crecimiento del porcentaje de cobertura a medida que más desarrolladores contribuyen funciones nuevas en core/libs/prx.
Vale repetir el matiz del porcentaje de cobertura: mide funciones conocidas y declaradas, no el total real de la superficie de PRX de PS5, que Sony nunca publicó completa. Es una métrica útil para medir el progreso del proyecto, pero no una promesa de qué fracción del catálogo de la consola llegará a correr.
Este enfoque tampoco es portable a cualquier destino. Si alguien quisiera llevar los mismos juegos a una arquitectura ARM, como la de un celular o una consola portátil, el relinker dejaría de bastar: ahí sí haría falta traducir instrucciones de CPU, porque x86-64 y ARM no comparten ni el conjunto de instrucciones ni la convención de llamada. El port layer sin emulación funciona exactamente en el caso en que AnyPS5 lo aplica: misma familia de CPU, distinto sistema operativo.
sequenceDiagram
participant J as Juego PS5
participant R as Shader recompiler
participant V as Validador SPIR-V
participant G as GPU via Vulkan
J->>R: shader compilado para GNM
R->>V: SPIR-V generado
V-->>R: validacion ok o error
R->>G: shader SPIR-V listo
Note over R,G: solo se valida si se compila con ANYPS5_ENABLE_SPIRV_TOOLS📖 Resumen en Telegram: Ver resumen
Tu próximo paso: cloná el repositorio de AnyPS5 con git clone --recursive, abrí la carpeta core/libs/prx y contá cuántas funciones de la biblioteca gráfica o de red ya están implementadas antes de evaluar si tu juego de PS5 favorito tiene chance de arrancar.
Preguntas frecuentes
¿Qué diferencia a AnyPS5 de un emulador de PS5?
AnyPS5 no interpreta instrucciones de CPU en tiempo real porque la PS5 y un PC moderno comparten arquitectura x86-64. En vez de emular, relinkea el ejecutable al formato nativo del sistema destino y reimplementa las bibliotecas de sistema PRX que el juego necesita.
¿Un port layer sin emulación funciona con cualquier juego de PS5?
No todavía. Cada juego depende de qué funciones de las bibliotecas PRX ya estén reimplementadas; si llama a una función que el proyecto no cubre, el proceso termina con una excepción en vez de seguir corriendo con un comportamiento aproximado.
¿Por qué AnyPS5 necesita reimplementar las bibliotecas PRX en vez de copiarlas?
Porque las PRX originales son propiedad de Sony y no pueden distribuirse ni reutilizarse directamente. El proyecto las reescribe desde cero, función por función, replicando el comportamiento esperado por los juegos.
¿Qué pasa si AnyPS5 encuentra una función del sistema que no conoce?
Lanza una excepción std::runtime_error, imprime el mensaje en la salida de error estándar y termina el proceso de inmediato, en vez de continuar con un estado no soportado.
¿Es legal usar AnyPS5 con mis propios juegos de PS5?
El proyecto se declara para interoperabilidad, investigación, preservación y compatibilidad, y no incluye ni requiere firmware o claves de Sony. La legalidad de usar un ejecutable concreto depende de cómo lo obtuvo cada usuario y de las leyes de su país.
Referencias
- GitHub: boykopovar/AnyPS5: repositorio oficial del proyecto, con el README que documenta el relinker, las bibliotecas PRX y la lista de compatibilidad.
- Wikipedia: PlayStation 5: especificaciones de hardware de la consola, incluyendo la CPU AMD Zen 2.
- GitHub: ValveSoftware/Proton: repositorio oficial de Proton, la capa de compatibilidad de Valve usada como comparación.
- Khronos Group: especificación de SPIR-V: formato intermedio de shaders usado por Vulkan y por el recompilador de AnyPS5.
- GitHub: KhronosGroup/SPIRV-Tools: herramientas oficiales de validación de módulos SPIR-V.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Anne Nygård en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios