What's new

xenia vids and compatibility


Dcemu.co.uk guy
So much happening with http://xenia.jp/ the xbox360 emulator this week, that i thought i'd do a round up of vids and shots of it in action, feel free to contribute.

A-Train HX

Sonic the hedgehog (2006)

Dragon ball raging blast


super meat boy

sonic 4 episode 1

sonic 4 episode 2

nights into dreams




Crazy Taxi

Doritos Dash of Destruction

Puzzle Bobble

Runner 2

Castle Crashers

Zuma Deluxe

Sonic CD

Last edited:


Dcemu.co.uk guy
Air Conflicts: Secret Wars

Way of the Samurai 3

youtuber John GodGames has done quite a few tests, so kudos to him on these vids.

Alien horminid hd

Bullet soul

under defeat hd

Dodonpachi Daifukkatsu BL

Death Smiles

sonic unleashed
Last edited:


New member
Xenia author/leader developer wrote an interesting comment on reddit about the development process.

I really should write a new blog series on this, as I've learned so much since I started so many years ago. I'd like to say I was able to just magically make it fast with all my leet skillz, but it took a lot of iteration, research, and depressing trial-and-error cycles in many cases.
The short of the trick is: use as much domain-specific knowledge as possible to solve the problem and don't try to take shortcuts.
The two areas most relevant to performance where this was applied was the CPU and GPU implementations.
For the CPU I tried to take a shortcut by reusing existing PPC cores. None supported all of the instructions the 360 has, none supported the bizarre hybrid 32/64bit mode (32b addresses but 64b registers), and many didn't support big-endian systems. After a bunch of time wasted on that 'shortcut', I tried to take another shortcut by using an existing JIT/compiler to do my translation. I wrote a simple PPC decoder and emitted code using LLVM, libjit, and asmjit. Unfortunately these all did not map well to the purpose for various reasons. Specifically both libjit and asmjit (at least at the time I was investigating them) didn't support any SIMD operations, had extremely rudimentary optimization passes, and just weren't as fast or lightweight as you'd think. LLVM, though really featureful and most people's first guess as to what would work, was almost worst than those two. LLVM's IR and optimization phases are designed for human-written code: in a JIT like this we are already starting with extremely optimized code spit out from a compiler that looks very different than anything that comes out of a C frontend. The hoops I had to jump through to get PPC translated to the LLVM IR, then the prospect of throwing out virtually all of LLVM's optimization passes and writing my own dramatically reduced the value. And then there's the performance: LLVM is slow, even on a good day. Especially when trying to do ahead-of-time translations (which to get most of the advantages of LLVM's LTO and global optimizations you need to do) - it would take 30-40mins to do most translations, and the results still weren't fantastic. So finally I said '**** it' and stopped trying to take shortcuts. Now I have my own PPC->x64 translator that does some pretty sophisticated optimizations that would be largely impossible to do in LLVM due to the fact that I have much more domain-specific knowledge about what I'm feeding it (memory aliasing rules, flow control possibilities, register use and side-effects, etc). It's fast to generate code (with the option to cache it to reduce the cost to zero, but I haven't needed it yet), easy to modify (it largely exists in a dozen files), and most importantly was fun to build. Going forward there are dozens of low-hanging fixes that could speed things up, but so far none have been required (most games run fast enough to crash in a reasonable amount of time ;)
For the GPU I originally started with trying to map things to D3D11. This didn't work very well as the programming model for D3D did not at all line up with what I was getting from the 360 (packets of commands for the GPU to execute). By moving to OpenGL 4.5 I was able to better approximate the input and avoid expensive translation. This is critical because of some fundamental operations the 360 performs by way of its unified CPU/GPU memory - it's effectively completely bindless, has nearly unlimited samplers at any stage, and can actually write to main memory from shaders (MEMEXPORT). By using the bindless features of OpenGL 4.5 for buffers and textures, persistently mapped buffers for doing the transfer, as well as indirect drawing I'm able to avoid expensive copies, translations, and hacks to work around limitations of the API. That said, there are still a ton of hacks here and areas where things just can't be fast with a current-gen API. That's where D3D12 and Vulkan come in: they are the closest thing to what the 360 GPU is trying to do, and save for a few things they still don't/can't have is the best we can get. Things like SPIR-V that will make it possible to generate shaders without using string concatenation will also be nice, but not as revolutionary as the rest of the API.
So yeah. A lot of time, effort, trial-and-error, and experience. It's been a lot of fun - and not going to lie even more fun now that some games are working :) Emulators are the most fun piece of software one can hack on if looking to learn more about every layer of computing, and even when I wind down on this project I'll probably start on another!


Update June 2016:

Mortal Kombat VS DC Universe ingame

Dante's inferno ingame

Dragon Ball Raging Blast ingame!

Ice Age : Dawn of the Dinosaurs ingame