Title. No need to go over it, but if you've seen the posts previously, you know why this is appearing. Please keep this subreddit a drama-free zone, and keep any discussions like such out of here.
- Graine25 and the other mods in this sub
Hello everyone! For the last couple of months, the ReXGlue team has been hard at work updating our Software Development Kit to better support Development teams in making static recomps. Over the past few months, Tom and I have been working hard on the DarwinBooks, and finally accomplished working Mac support all the way to Ventura within our vendored translation layers.
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 and optimizations for specific titles, given they have spent a significant amount of time reversing their game.
Bringing the runtime up on macOS surfaced a handful of platform mismatches worth calling out on their own, beyond the headline Vulkan work:
- Bring up `ReXGPU-Xenos` on macOS by running the existing Vulkan backend through MoltenVK: valid SPIR-V for rectangle-list topology, face culling disabled on legacy AMD Metal, RGBA8 loaders for packed 16-bit textures MoltenVK can't sample directly, and a pinned Vulkan-Loader/MoltenVK build staged for macOS consumers instead of relying on whatever the system has.
- Mach-O symbol aliasing: `DEFINE_REX_FUNC` leaned on `__attribute__((alias(...)))` so hooks could override a guest function; Mach-O rejects that outright. Swapped in a weak, `musttail`-tail-called thunk for Apple targets so overriding still works without a real alias.
- Windowing goes through Cocoa Added a `CAMetalLayerSurface` obtained from SDL's Cocoa driver, since macOS has no Win32Hwnd or XcbWindow to present through — Vulkan needs a `CAMetalLayer` there instead.
All of our features like achievements, the ReX API, and every other developmental tools that we offer should be usable with this system added to our Support. We encourage developers to replace the rendering system (ReXGPU-Xenos) in their title when releasing a project with ReXGlue. Our rendering implementation with MoltenVk can work for a multitude of titles, but it will still be significantly lacking in performance since it is meant to be a testing/translation layer rather than a finished implementation that can qualify as a native PC Port.
Link to our repository - Install is as easy as `brew install cmake ninja vulkan volk` and Xcode from the App Store
The video that I have attached is a recomp attempt that I set as a testing layer for the game Raskulls (XBLA). The gameplay clearly shows, but it’s definitely possible for a development team, their own implementation of the system, and make it look proper. We definitely plan on releasing more titles that run properly on Apple hardware rather than just showing you guys development software, so stay tuned! I’ve been in MacUser all my life so I’m happy to continue working on the platform get you guys caught up.
Happy gaming
- Graine25
Hello everyone. Over the past few weeks, we have seen tons of interest in both Recomps and Decomps. It's amazing to see everyone so interested in the platform, after the early beginnings many years ago, to now all these incredible frameworks making it easy to start a project within minutes. Of course with these changes, people who have interest in posting about them and gathering attention/support for their project at hand. Rather than spamming and deleting posts, the mod team of the subreddit have decided to update the flairs for everyone 🙂
First things first, with the amount of people interested in all console, we have decided to make tags for the big three console makers — PlayStation, Xbox, and Nintendo. Additionally, we noticed that there were templates like ReXGlue and ModernGekko being developed, so we have also added a Framework Development tag, specifically for those. We're really excited to see the progress on later generation architectures, so keep at it!
Most importantly, we have seen people release and discuss their projects early and claim that it is a native PC port, despite there being significant optimization needed to be made. Rather than us striking all these posts down, we have just decided to make three simple tags to distinguish the progress level of each:
Please be careful when using any of these three tags. Do not use one incorrectly because you want more recognition — especially the Optimized Production tag. We're still here promoting these projects because we really love preserving old titles, but we don't want to guide people the wrong way. Some of the original tags that we were using before like the AI one is still there. We're not sure how detrimental it is to use an LLM, but we firmly believe that optimizations and understanding where your project stands is more important than trying to decide if an LLM made it.
For more clarifications on any of these tags, feel free to leave a comment down below, and I'll be happy to edit the post or answer your questions appropriately. Happy Recomping!.. Or Decomping?... Whatever we do here
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 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!
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.
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.
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!
A rather speculative list, but just some ideas we have planned. Feedback welcome!
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!
