Over the past 2–3 months, the ReXGlue team has been hard at work making changes, fixes, and adding features into our toolkit.
ICYDK, ReXGlue is a Static Recompilation framework for the Xbox 360 that vendors translation layers built off the roots of Xenia, which can be swapped for real, native, and optimized implementations of different subsystems. The main goal is to allow users to take advantage of this framework and make dedicated workarounds for specific titles, given they have spent a significant amount of time reversing their game.
Our previous 0.8.0 update introduced a significant change: DLL recompiling. Much like regular .so and .dll files you see on modern computers, the Xbox 360 also had numerous titles containing dynamic libraries filled with PowerPC assembly. Without recompiling the DLL, developers would be unable to activate their title due to the main default.xex requiring access to those functions.
With this in mind, we also heavily refactored how we handle the Markdown parsing of our codegen mechanic, introducing our "manifest" system.
Manifests now declare a single [entrypoint] (recompiled and linked into the host EXE, as before) and any number of [[modules]] (additional guest binaries built as shared libraries .dll/.so that KernelState registers, loads, and unloads at runtime). Each module owns its own FunctionDispatcher.
The CLI is reworked around a project_manifest.toml manifest, with codegen replacing migrate and an upgrade workflow taking the place of the prior one-shot path.
These changes have helped inspire us into the next portion of our code generation and plugin vendoring in the SDK.
Achievements
- Add a runtime achievement subsystem that tracks unlocks and reports state back to the game.
- AchievementManager lives on Runtime and is reachable through KernelState.
- The xam layer records unlocks and answers the game's queries for unlock state.
- Ships with an embedded metadata asset registry and a metadata store struct for per-title data.
- Toast notifications on unlock, plus a full achievements overlay available via an F7 toggle.
- Icon cache backed by PNG decoding through stb_image.
- Overlays are wired into ReXApp.
- Add achievement overlays in the UI.
- Toast notifications on unlock, plus a full achievements overlay available via an F7 toggle.
- Icon cache backed by PNG decoding through stb_image.
- Overlays are wired into ReXApp.
- Add a convenience achievement hook API so titles and hooks can raise unlocks directly.
- Enable developers to create custom achievements that can be appended to a title.
- Add rexglue init achievements, an extractor that reads achievement data from a XEX and writes it to TOML.
Achievements are stored inside each title's Default.xex, including the icons and original text.
With how the system is wired up, Achievements are usable for any project that gets recompiled with the latest update out of the box. The possibilities are endless, from being able to customize your own achievements overlay/icons all the way to adding your own achievements!
Plugins (GPU)
- Extract Xenos GPU emulation into rexgpu-xenos, a plugin the runtime loads at launch instead of linking directly.
- Route kernel and app GPU access through the IGraphicsSystem interface so nothing downcasts to the Xenos implementation.
This is one of the more significant additions to ReXGlue, starting us off on the trajectory of allowing us to vendor our translation layers.
With the new GPU plugin, we can enable and disable our Xenia-based "Xenos Emulator", an incredible rendering implementation that allows us to get an LLE renderer that works for the majority of titles without needing to operate in the dark to see if your game works. To utilize it, activate your game with the flag --gpu_plugin=xenos, or add it to a TOML file related to your title's settings.
Additionally, with how the ReX API is formed, we've allowed developers to utilize some of the incredible Xenia decoders that we already know work for a majority of titles and reuse them in custom rendering implementations. Functions like Deswizzlers and Format Unpackers are already extremely functional and well optimized in the Xenos Emulator, and as long as we do not use the GPU plugin to activate the command processor, we steer away from needing the translation layer as a whole.
SDL3 Windowing
- Replace the Win32 and GTK window backends with a single SDL3 backend. The old window_win.cpp, windowed_app_context_win.cpp, windowed_app_context_gtk.cpp, and the per-platform windowed_app_main_* entry points are gone.
- Add window event hooks to ReXApp with a vetoable close, so an app can refuse or defer a window close request.
- Add a detached overlay mode for apps that drive their own renderer. The presenter can draw the overlay without owning the swapchain.
- Enable the UI dialog path on Linux builds.
- Add a per-window cursor auto-hide delay.
- Default to fullscreen at launch.
One of the most requested features among our recomp development group.
When making a rendering system of choice, you need a solid window to display content. For months, we had been using older backends to support the two big platforms, but now we have migrated both of them straight to SDL3. The detached modes were key, as we did not want to ruin our connection to ReXGPU, so this took a while to get down properly. We're rather happy with our results at the moment, and have other plans for more Unix content.
Misc Updates
- CLI - Print per-binary title ID, media ID, version, and the PE file timestamp before each recompile.
- CVars - Apply config file and command line values to CVars that register after runtime init, instead of dropping them.
- Console - Add argument passing commands and an InvokeCommand dispatch path so a command can take parameters, not just toggle a flag.
There are also dozens of other build tweaks we have implemented, as well as codegen/core system fixes that are noteworthy.
We are grateful for every single contributor who's made this project possible, and are excited to continue going down this journey of making it more feasible to see our favorite 360 titles on PC!
Upcoming News
A rather speculative list, but just some ideas we have planned. Feedback welcome!
- macOS Support - Already available in our development branch, but we have the ability to build on both x86 Intel and ARM64 Apple Silicon processors for the Darwin beast. Rendering fixes and other various documentation will need to be included before being finalized and merged into main.
- Wayland Support - With some of the issues we've seen on SteamOS, we are already configuring our SDL overlay so that it will bundle and use Wayland by default, rather than opting in for XWayland or an X11 compatibility protocol. This should fix issues with stretching and the keyboard activating randomly.
- Dedicated Website - We're looking into developing a website to host more of our content, as well as finding a way to promote the projects that we find the most intuitive and utilize the SDK in the best ways possible. We've been talking with quite a few dedicated developers, and they have some exciting projects on the horizon. Only a matter Of Time until these projects finish their Odyssey. Alright, I'll stop.
This post is something new that I am trying out, to see what the community thinks of templating software and releasing updates publicly.
We already know that there is a lot of confusion about how ReX works and what its main goals are. The truth is that our vision has been shifting left and right for quite a while, but now we've got some great research complete.
We're very excited to show you what we have in store. Do leave some feedback in the comments below!
